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PREFACE 


The  Department  of  Defense  funded  the  development  of  the 
Ada  Compiler  Validation  Capability  (ACVC)  for  use  in  the 
validation-testing  of  Ada  compilers.  The  ACVC  was  targeted 
to  test  only  those  compilers  which  implement  the  entire  Ada 
language.  It  appeared  that  the  development  of  a  testing 
capability  for  evolving  Ada  compilers  would  be  a  very  useful 
tool  for  compiler  developers.  The  need  for  such  a  tool 
coupled  with  my  desire  to  learn  more  about  Ada  led  to  the 
selection  of  this  thesis  topic. 

I  would  like  to  thank  my  advisor,  Captain  Roie  R. 
Black,  for  all  the  time  and  guidance  he  has  given  me.  His 
ideas  and  suggestions  during  the  course  of  the  project  were 
most  helpful.  I  would  also  like  to  thank  my  thesis-committee 
members,  Lieutenant  Colonel  Harold  W.  Carter  and  Major 
Michael  R.  Varrieur.  Their  suggestions  and  commments  were 
very  valuable. 

Deep  gratitude  is  also  expressed  to  Patricia  A.  Knoop 
of  the  Language  Control  Branch,  Computer  Operations 
Division,  Aeronautical  Systems  Division,  Wrlght-Patterson 
AFB,  Ohio,  who  originally  proposed  the  topic  and  provided 
the  resources  needed  during  the  project. 

Finally,  I  would  like  to  thank  my  parents  for  all  the 
support  and  encouragement  they  have  given  me. 
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ABSTRACT 


This  project  consisted  of  a  preliminary  design  and  a 
partial  implementation  of  a  tool  which  modifies  the  existing 
Ada  Compiler  Validation  Capability  (ACVC)  test  set  so  it  can 
be  used  to  test  evolving  Ada  compilers.  The  project 
evaluated  the  feasibility  of  repackaging  each  of  test 
classes  found  in  the  ACVC  and  suggested  methods  for 
repackaging  the  tests.  The  tool  developed  uses  a 
table-driven  parser  which  parses  the  July  1980  proposed 
standard.  It  uses  output  from  the  parser  to  generate  a 
representation  of  a  test  program.  Once  the  representation  is 
developed,  unsupported  langauge-f eatures  are  removed  from 
It.  The  remaining  representation  is  output  as  a  valid  test 
program. 


vi 


1.  INTRODUCTION 


In  order  to  combat  the  rising  cost  of  software  in 
embedded  computer  systems,  the  Department  of  Defense  (DoD) 
sponsored  efforts  which  led  to  the  design  of  the  Ada 
programming  language.  The  efforts  were  not  limited  to  the 
design  of  a  new  programming  language;  DoD  also  sponsored 
efforts  to  develop  the  Ada  Programming  Support  Environment 
(APSE)  and  the  Ada  Compiler  Validation  Capability  (ACVC). 

This  thesis  project  is  based  on  the  results  of  the  ACVC 
developed  by  "The  Software  Technology  Company"  (SofTech). 
Specifically,  it  investigates  the  problem  of  modifying  tests 
contained  in  the  ACVC  so  they  can  be  used  to  test  evolving 
Ada  compilers  (described  in  Appendix  A).  The  project  was 
proposed  and  sponsored  by  the  Language  Control  Branch, 
Computer  Operations  Division,  Aeronautical  Systems  Division 
Computer  Center,  Wright-Patterson  AFB. 

This  chapter  begins  by  providing  background  information 
on  the  development  of  the  Ada  programming  language  and  the 
ACVC.  It  concludes  with  an  introductory  description  of  the 
thesis  project. 


1.1  Background 

—  DoD's  Software 

Problem 

Intensive 

studies  completed 

in  the 

early 

1970's 

identified  the 

software  costs 

associated 

with 

embedded 

computer  systems  as  the  most 

significant 

DoD 

software 
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problem.  These  studies  also  revealed  that  the  majority  of 
the  embedded  computer  system  costs  were  related  to  software 


maintenance  rather  than  software  development  (Ref  4:24). 

1.1.1  The  proliferation  of  languages 

A  principle  factor  contributing  to  the  rising  cost  of 
embedded  computer  system  software  was  the  large  number  of 
languages  used  within  the  DoD.  Over  450  general-purpose 
languages  and  dialects  were  being  used,  and  the  majority  of 
these  languages  were  used  in  embedded  computer  systems. 
This  lack  of  programming  language  commonality  contributes  to 
the  rising  software  costs  in  several  ways  (Ref  4:26): 

(1)  it  requires  duplication  in  training  and  maintenance 
for  the  languages,  their  compilers,  «.  nd  their 
associated  software  support  packages. 

(2)  it  limits  communication  among  software 
practitioners. 

(3)  it  results  in  support  software  being  developed 
which  can  only  be  used  on  one  project. 

(4)  it  ties  software  maintenance  to  the  original 
developer . 

(5)  it  limits  the  development  of  support  and 

maintenance  software. 

(6)  it  limits  the  applicability  of  new  support 
software. 

(7)  it  creates  a  situation  in  which  the  adoption  of  an 


existing  language  by  a  new  project  can  be  more  risky 
and  less  cost-effective  than  the  development  of  a  new 
programming  language  specialized  to  the  project. 

1.1.2  The  High  Order  Language  Working  Group 

In  order  to  resolve  the  problems  presented  by  the  large 
number  of  languages,  the  DoD  began  a  common  high  order 
language  programming  effort.  To  coordinate  this  effort,  a 
High  Order  Language  Working  Group  (HOLWG)  was  formed.  This 
group  consisted  of  representatives  from  the  Army,  Navy,  Air 
Force,  Marine  Corps,  Defense  Communications  Agency  and 
Defense  Advanced  Research  Projects  Agency.  The  HOLWG  was 
chartered  to  "investigate  the  establishment  of  a  minimal 
number  of  common  high-order  computer  programming  languages 
to  be  used  in  the  development,  acquisition,  and  support  of 
computer  resources  embedded  within  Defense  Systems"  (Ref 
4:27). 


1.1.3  The  search  for  a_  solution 

The  first  step  taken  by  the  HOLWG  was  to  adopt  an 
interim  list  of  seven  programming  languages  approved  for  use 
in  the  development  of  new  defense  system  software.  The 
second  step  was  to  determine  the  characteristics  of  a 
general-purpose  programming  language  suitable  for  embedded 
computer  applications.  These  characteristics  were  put  in 
the  form  of  requirements  which  were  circulated  to  the 
military,  industrial  and  academic  communities  for  comments. 
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After  the  comments  were  received  and  evaluated,  a  new 
requirements  list  was  circulated.  This  process  was  repeated 
until  a  suitable  language  description  was  defined. 

The  next  step  was  an  evaluation  to  determine  if  any 
existing  language  met  the  requirements  specified  in  the 
language  description.  The  results  obtained  from  evaluations 
of  23  different  languages  led  the  HOLWG  to  conclude  that  no 
existing  language  satisfied  the  requirements  well  enough  to 
be  adopted  as  a  common  language.  Even  though  no  existing 
language  was  found  suitable,  the  evaluators  did  agree  that 
it  was  possible  to  design  a  single  language  that  would  meet 
all  the  requirements.  Based  on  this  finding,  the  HOLWG 
began  directing  their  efforts  toward  the  design  of  a  new 
language  (Ref  4:27). 

1.1.4  Design  Phase 

The  design  phase  evaluated  fifteen  design  proposals 
received  for  the  new  language  description.  Of  these,  four 
were  selected  for  parallel  development  efforts.  At  the 
conclusion  of  these  efforts,  the  language  definition 
developed  by  CII  Honeywell-Bull  was  accepted  as  the  basis 
for  the  new  DoD  language,  now  known  as  Ada  (Ref  4:29). 

1.1.5  The  need  for  a  standard 


The  key  to  the  economic  success  of  Ada  is  the 
portability  of  programs,  programmers,  compilers  and  software 
tools.  To  insure  portability  it  was  essential  that  Ada  be 


established  as  a  clear  and  unambiguous  standard.  In 
addition  a  means  for  discouraging  and  detecting  compilers 
which  did  not  correctly  implement  the  standard  was  needed. 
This  led  to  the  trademarking  of  the  name  Ada  and  the 
development  of  a  means  for  validating  compilers. 

4 

1.1.6  The  Ada  Compiler  Validation  Capability 

The  Ada  Compiler  Validation  Capability  (ACVC)  effort 
began  at  SofTech  in  September  of  1979,  and  the  first  version 
was  completed  in  1981.  It  is  especially  significant  because 
it  makes  Ada  the  first  programming  language  to  have  a  means 
of  enforcing  the  language  specification  before  diverse 
implementations  begin  to  appear  (Ref  6:57). 

The  primary  purpose  of  the  ACVC  was  to  determine  if  Ada 
compilers  comply  with  the  language  definition  contained  in 
the  "Reference  Manual  for  the  Ada  Programming  Language". 
The  ACVC  was  also  designed  to  help  the  implementers  comply 
with  the  language  standard,  by  pointing  out  potential 
implementation  difficulties  (Ref  6:57). 

The  current  version  of  the  ACVC  has  three  main 
components  (Ref  2:1-1): 

1.  An  Implementers  Guide  ( I G )  which  describes  the 
implementation  implications  of  the  Ada  standard  and 
conditions  which  are  to  be  checked  by  the  validation 
tests . 
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2.  Test  ’ programs  that  are  submitted  to  the  compiler 
being  tested.  The  current  version  of  the  ACVC  has  over 
1400  tests  designed  to  check  the  compilers  conformance 
to  the  language  specification. 

3.  Validation  support  tools  that  are  used  to  prepare 
tests  for  execution  and  to  analyze  the  results  of 
execution . 

1.1.7  Ada  compiler  development 

Widespread  acceptance  of  the  Ada  programming  language 
is  not  likely  to  occur  until  compilers  become  readily 
available.  Currently  there  are  a  large  number  of  compiler 
development  efforts  under  way.  The  first  successful 
validation  of  an  Ada  compiler  was  expected  to  occur  in  late 
1982. 

A  large  number  of  the  compiler  development  efforts  are 
being  directed  at  the  microcomputer  market.  The  approach 
many  of  these  efforts  have  taken  is  to  develop  a  basic 
subset  of  the  full  Ada  language.  Once  the  subset  is 
developed,  enhancements  are  then  added  to  it  until  the 
entire  language  is  implemented  (Appendix  A  provides  a  more 
detailed  discussion  of  a  typical  development  effort). 

Developers  of  these  subsets  have  encountered  a  large 
number  of  problems.  Two  of  the  major  problems  are  the 
complexity  of  the  language  and  the  lack  of  adequate  support 
tools  needed  during  the  compiler  development  process. 
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1.1.8  The  need  for  an  incremental  validation  capability 

A  significant  aspect  of  the  ACVC  is  that  it  is  targeted 
to  test  only  those  compilers  which  are  completed  and 
implement  the  entire  language.  As  a  result,  the  ACVC  uses 
language  features  which  are  likely  to  be  supported  only 
toward  the  end  of  the  compiler  construction.  This  severely 
limits  the  usefulness  of  the  ACVC  during  the  development 
phases  of  a  compiler.  This  is  significant  because  the  cost 
of  repairing  an  error  is  reduced  if  it  is  detected  soon 
after  it  is  committed.  This  makes  the  availability  of 
adequate  test  tools  for  compilers  essential  during  the 
developmental  stages.  Errors  made  during  the  early  stages  of 
the  compiler  development  could  be  extremely  costly  if  they 
go  undetected  until  attempts  are  made  to  validate  the 
compiler . 

1.2  OBJECTIVE 

The  objective  of  this  project  was  to  develop  techniques 
for  transforming  the  existing  ACVC  test  set  into  a  version 
which  could  be  used  to  test  evolving  Ada  compilers. 

1.3  GENERAL  APPROACH 

The  approach  taken  in  this  project  was  significantly 
influenced  by  the  requirement  for  Ada  compilers  to  pass  the 
ACVC.  As  a  result  of  this  requirement,  the  project  was 
directed  toward  modifying  the  current  set  of  ACVC  tests 
rather  than  attempting  to  develop  a  completely  new  test  set. 
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The  approach  taken  was  to  remove  any  language-features 
used  in  the  test  set  that  are  not  supported  by  the  compiler 
being  tested.  Once  the  unsupported  features  are  removed,  the 
compiler  should  pass  the  remaining  portion  of  the  test  set. 
Automating  the  process  which  removes  unsupported  features 
from  the  tests  would  allow  a  new  test  set  to  be  developed 
every  time  new  features  are  added  to  the  compiler. 

The  advantage  of  this  approach  is  that  the  actual  ACVC 
tests  are  being  used.  Tests  are  incorporated  into  the  test 
set  as  soon  as  the  language-features  used  by  the  test  are 
supported  by  the  compiler.  The  test  set  will  continue  to 
grow  as  the  compiler  becomes  more  complete.  Passing  tests  or 
portions  of  tests  used  in  the  ACVC  should  provide  some 
degree  of  confidence  that  the  actual  ACVC  tests  can  be 
passed.  It  will  also  help  point  out  deficiencies  in  the 
compiler  early  in  the  development  stages. 

1.4  SEQUENCE  OF  PRESENTATION 

The  project  consisted  of  three  major  phases,  which  are 
described  in  the  following  chapters.  The  first  phase  was  an 
analysis  of  the  existing  ACVC.  This  phase  studied  the 
different  types  of  tests  contained  in  the  ACVC  and 
identified  the  use  of  language  features  in  the  tests  which 
were  not  related  to  the  test  objectives  (language  features 
that  are  used  unnecessarily  will  be  referred  to  as 
langauage-f eature  dependencies).  The  analysis  phase  then 
looked  for  ways  the  tests  could  be  repackaged  without  the 
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language-feature  dependencies. 

The  second  phase  of  the  project  investigated  the 
problem  of  transforming  the  test  set  into  a  version  that 
could  be  used  to  test  evolving  compilers.  This  focused  on 
the  removal  of  features  not  yet  supported  in  an  evolving 
compiler.  Particular  emphasis  was  placed  on  the  automation 
of  a  process  to  accomplish  this. 

The  third  phase  was  a  partial  implementation  of  the 

tool  described  in  the  second  phase.  The  purpose  of  the 
partial  implementation  was  to  demonstrate  that  it  was 
possible  to  automate  the  removal  of  unsupported  language 
features . 
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2.  ANALYSIS 


2.1  Introduction 

The  first  step  in  this  project  was  a  detailed  analysis 
of  the  existing  ACVC  test  set.  The  purpose  of  this  analysis 
was  to  identify  the  language-f eature  dependencies  contained 
in  the  ACVC  test  set  and  determine  what  impact  their  removal 
would  have  on  the  test  set.  This  requires  a  basic 
understanding  of  the  ACVC's  approach  to  testing,  its  design 
goals,  its  organization,  and  the  general  structure  of  the 
test  set. 

This  analysis  is  broken  into  four  sections.  The  first 
section  provides  background  information  on  the  testing 
approach,  the  design  goals,  and  the  organization  of  the  test 
set.  The  second  section  looks  at  the  the  general  structure 
of  the  test  set,  while  the  third  section  provides  a  detailed 
look  at  some  of  the  tests  found  in  the  test  set.  The  fourth 
section  summarizes  the  results  of  the  analysis. 

2.2  Background 

The  first  step  in  the  analysis  of  the  ACVC  was  to 
review  the  test  set.  This  review  looked  at  the  testing 
approach  taken  by  SofTech,  some  of  the  factors  that 
influenced  the  design  of  the  test  set,  and  the  organization 
of  the  test  set. 
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Black-box  and  white-box  testing  are  the  two  generally 
accepted  approaches  to  testing.  White-box  testing  is 
predicated  on  a  detailed  knowledge  of  the  internal  workings 
of  a  product.  Tests  are  designed  to  determine  if  internal 
operations  are  performed  according  to  specification. 
Black-box  tests,  on  the  other  hand,  are  designed  to 
demonstrate  that  the  functions  a  product  is  supposed  to 
perform  are  operational.  The  internal  structure  of  the 
software  is  not  considered  when  designing  black-box  tests 
(Ref  7-292). 

The  designers  of  the  ACVC  used  the  black-box  approach 
to  testing.  This  was  appropriate  since  the  ACVC  was  designed 
to  determine  only  if  the  compiler  conformed  to  the  language 
definition.  Issues  such  as  quality  and  efficiency  were  not 
considered  when  designing  the  test  set.  Also,  to  use  the 
white-box  approach  would  have  required  a  detailed  knowledge 
of  each  compiler  submitted  for  validation.  Since  the  manner 
in  which  various  tasks  are  implemented  may  differ  greatly 
between  compilers,  a  new  test  set  would  be  required  for  each 
compiler  submitted  for  validation. 

2.2.2  Test  set  design 

Before  making  any  changes  to  the  test  set  several 
factors  which  influenced  its  design  must  be  considered.  This 
section  will  briefly  describe  some  of  the  design  goals  of 
the  test  set  and  some  of  the  factors  which  had  a  significant 


influence  on  the  design  of  the  test  set. 

One  of  the  ACVC's  principle  design  goals  was  to  develop 
a  test  set  which  was  portable.  To  accomplish  this,  SofTech 
adopted  the  following  set  of  coding  standards  in  their  test 
set  (Ref  3:A-2): 

(1)  The  source  line  length  in  test  programs  does  not 
exceed  72  characters. 

(2)  Tests  are  limited  to  the  basic  55  character  set. 

(3)  Numeric  values  were  limited  so  that  a  12  bit  word 
size  is  sufficient. 

(4)  Array  sizes  are  kept  small. 

(5)  No  tests  use  both  fixed  and  floating-point  types 
unless  the  test  objective  addresses  interactions  between 
these  types. 

(6)  Unnecessary  use  of  fixed  and  floating-point  types, 
integer  types  other  than  INTEGER,  access  types,  tasks, 
generics,  representation  specifications,  subunits, 
exceptions,  overloading,  renaming,  private  types,  and 
input/output  is  prohibited. 

In  addition  to  insuring  that  the  test  set  is  portable, 
these  coding  standards  also  help  reduce  the  number  of 
failures  that  are  not  related  to  the  test  objectives  (Ref 
6:60). 

Another  design  goal  was  to  reduce  the  manual 
intervention  required  when  using  the  test  set.  It  resulted 
in  the  development  of  a  large  number  of  small  tests  which 
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require  no  modification  during  the  testing  process  (Ref 
6:59). 


The  need  for  the  ACVC  to  be  constantly  updated  also 
impacted  on  its  design.  Black-box  tests  cannot  guarantee 
that  software  is  error  free.  Therefore  as  errors  are  found 
in  compilers  which  successfully  passed  the  validation  test, 
new  tests  must  be  developed  to  insure  that  these  errors  are 
identified  in  future  validation  attempts.  This  was  another 
reason  the  use  of  small  tests  was  adopted  in  the  test  set 
(Ref  6:59). 

Finally,  the  decision  to  test  only  completed  compilers 
was  significant  since  it  allowed  features  normally  supported 
only  towards  the  end  of  a  compiler's  development  to  be  used. 
The  prime  example  of  this  is  a-  separately  compiled  package 
used  to  report  test  results  (Report  Package). 


2.2.3  Test  Set  Organization 

The  tests  in  the  test  set  are  organized  to  correspond 
with  objectives  contained  in  the  Implementers '  Guide.  These 
objectives  can  be  broken  into  eleven  major  areas: 


1.  Lexical  Elements 

2.  Declarations  and  Types 

3.  Names  and  Expressions 

4.  Statements 

5.  Subprograms 

6.  Packages 

7.  Visibility  Rules 

8.  Tasks 

9.  Program  structure  and  compilation  issues 

10.  Exceptions 

11.  Generic  program  units 


The  Implementer s '  Guide  was  designed  to  correspond  with 
the  "Reference  Manual  for  the  Ada  Programming  Language" 
(LRM) .  Objectives  found  in  the  IG  were  based  on  the  language 
definition  contained  in  the  LRM. 

The  language  definition  was  reviewed  to  identify 
potential  implementation  difficulties.  A  set  of  test 
objectives  was  then  developed  to  insure  these  potential 
deficiencies  were  identified  during  testing.  The  final  step 
was  to  develop  tests  which  would  accomplish  the  test 
objectives . 

Figures  2.1  and  2.2  reflect  the  relationship  that 
exists  between  the  LRM  and  the  IG.  Figure  2.1  is  an  example 
of  the  language  definition  taken  from  the  LRM,  while  Figure 
2.2  is  a  list  of  the  test  objectives  taken  from  the  IG  that 
correspond  to  the  language  definition  in  Figure  2.1. 

The  language  definition  presented  in  the  LRM  uses  a 
simple  variant  of  the  Backus-Naur  form  (BNF).  The  BNF  is 
used  to  specify  the  rules  for  forming  valid  programs.  These 
rules  are  called  productions.  Figure  2-1  shows  the 
productions  that  define  an  identifier  in  Ada.  The  LRM  uses 
square  brackets  to  enclose  optional  items,  braces  to 
identify  items  which  may  occur  repeatedly  (zero  or  more 
times),  and  vertical  bars  (|)  to  separate  alternative  items. 
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2.3  Identifiers 

Identifiers  are  used  as  names  (also  as  reserved  words). 
Isolated  underscore  characters  may  be  included.  All 
characters,  including  underscores,  are  significant. 

identifier 

letter  ^[underscore]  letter^or^digit^ 

letter_or_ digit  letter  |  digit 

letter  upper_case_letter  |  lower_case_letter 

Note  that  identifiers  differing  only  in  the  use 
of  corresponding  upper  and  lower  case  letters  are 
considered  as  the  same. 


Figure  2-1.  LRM  definition  of  identifier  structure  (Sec  2.3) 


The  productions  shown  in  figure  2-1  show  that  identifiers 
must  begin  with  a  letter.  They  also  show  that  consecutive 
underscores  are  not  permitted  in  identifiers,  and  that 
identifiers  cannot  end  with  an  underscore. 
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Test  Objectives  and  Design  Guidelines 


1.  Check  that  upper  and  lower  case  letters  are 
equivalent  in  identifiers  (including  reserved  words) 

Implementation  Guideline:  Try  some  all-upper, 
all-lower,  and  mixed  case  identifiers. 

2.  Check  that  consecutive,  leading,  and/or  trailing 
underscores  are  not  permitted  in  identifiers. 


3.  Check  that  identifiers  can  be  as  long  as  the  maximum 
input  line  length  permitted  by  the  implementation 
and  that  all  characters  are  significant  (e.g.,  not 
just  the  first  8  or  16,  or  not  just  the  first  m  and 
last  n  characters).  Try  identifiers  serving  as 
variables,  enumeration  literals,  subprogram  names, 
parameter  names,  entry  names,  record  component  names 
type  names,  package  names  (both  library  units  and 
and  subunits),  statement  labels,  block  labels,  loop 
labels,  task  names,  and  exception  names. 


Implementation  Guideline  :  Maximum  length  subprogram 
names  and  package  names  should  be  checked  in  separate 
tests . 


4.  Check  that  ?  Z  @  #  '  are  not  permitted  in 

identifiers . 


Figure  2-2.  ACVC  test  objectives  and  design  guidelines 
(section  2.3) 


2 . 3  General  Structure 

The  second  step  in  the  analysis  looked  at  the  structure 
of  the  test  set.  The  test  set  has  two  primary  components, 
the  Report  Package  and  the  tests.  This  section  will  present 
an  overview  of  each  of  these  components. 

2.3.1  Report  Package 

The  report  package  is  a  separately  compiled  group  of 
routines  used  to  automate  the  process  of  reporting  test 
results.  They  are  independent  of  the  tests  themselves,  and 
provide  the  mechanism  for  reporting  pass/fail  results  of 
executable  tests  (Ref  3:A-1). 

The  report  package  (see  Appendix  B  for  the  source 
listing)  contains  the  following  subprograms  (Ref  3:B-1): 

1.  Test:  This  procedure  is  called  at  the  beginning  of 
all  executable  tests.  It  saves  the  test  name  and 
outputs  the  name  and  description. 

2.  Failed:  This  procedure  outputs  a  failure  message 

that  includes  a  brief  description  of  what  failed. 

3.  Comment:  This  procedure  outputs  a  comment  message. 

4.  Result:  This  procedure  is  called  at  the  end  of 
each  test.  It  indicates  whether  whether  the  test  has 
passed  or  failed. 
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5. 


Put_Msg:  This  procedure  formats  and  outputs 
messages.  It  can  only  be  called  within  the  package 
itself . 

6.  Ident_int,  Ident_char,  Ident_bool,  and  Ident_str: 
These  functions  are  dynamic  value  routines  which  serve 
as  identity  functions  for  the  types  Integer,  Character, 
Boolean  and  String. 

7.  Equal:  A  recursive  equality  function  for  the  type 
integer . 

2.3.2  Tests 

The  tests  in  the  ACVC  are  written  to  correspond  to  the 
objectives  listed  in  the  Implementers '  Guide.  There  are  six 
distinct  classes  of  tests  which  may  be  found  in  the  test  set 
(Ref  6:60): 

Class  A:  These  tests  are  designed  to  compile  and 
execute  without  any  errors.  No  checks  are  made  at 
run-time  to  determine  if  a  test  objective  has  been  met. 

Class  B:  These  tests  are  illegal  and  should  fail 
compilation.  They  are  passed  if  all  errors  are 
detected  at  compile  time  and  all  legal  statements  are 
considered  legal. 
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Class  C:  These  tests  are  designed  to  compile  and 
execute.  They  are  self-checking. 


Class  D:  These  are  capacity  tests.  There  are  no 

pass/fail  criteria. 

Class  E:  These  are  tests  that  check  whether  certain 
implementation  dependent  options  have  been  provided. 
They  also  determine  how  ambiguities  in  the  language 
standard  have  been  resolved. 

Class  L:  These  are  illegal  programs  that  are  expected 
to  fail  at  link-time.  The  failure  must  occu^  before 
any  declarations  in  the  mai<  prog/ a*’  or  any  units 
referenced  in  the  main  program  are  elaborated.  They  may 
fail  compilation  in  some  implementations. 

2 .4  Detailed  Analysis 

This  section  will  provide  a  detailed  analysis  of  each 
type  of  test  found  in  the  test  set.  It  will  specifically 
address  four  questions: 

(1)  What  language-feature  dependencies  exist  ? 

(2)  What  effect  will  their  removal  have  ? 

(3)  How  can  the  test  be  repackaged  to  eliminate  the 
language-feature  dependencies  ? 

(4)  Can  the  repackaged  tests  be  used  to  test  evolving 
compilers,  or  are  further  modifications  needed  ? 
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2.4.1  Class  A 


As  mentioned  before,  Class  A  tests  are  designed  to 
compile  without  any  errors.  Approximately  two  percent  of  the 
tests  found  in  the  test  set  are  Class  A  tests.  A  typical 
example  of  a  Class  A  test  is  shown  in  figure  2-3. 

The  test  shown  in  figure  2-3  uses  several  language 
features  which  do  not  contribute  to  the  accomplishment  of 
the  test  objectives.  The  first  dependency  is  the  WITH  REPORT 
statement.  It  is  used  to  indicate  the  dependency  of  the 
procedure  on  the  Report  Package.  The  second  dependency  is 
the  USE  REPORT  statement,  which  acts  like  a  declaration  in 
the  procedure.  The  final  two  dependencies  are  the  procedure 
calls  TEST  and  RESULT.  Both  of  these  procedures  are  found  in 
the  separately  compiled  REPORT  package. 

After  identifying  the  dependencies,  the  next  step  is  to 
determine  what  effect  their  removal  would  have  on  the  test 
set.  The  first  consideration  is  whether  the  test  objectives 
will  still  be  accdmplished .  Since  the  purpose  of  the 
statements  containing  the  dependencies  is  to  report  the 
pass/fail  status  of  the  tests,  there  is  no  impact  on  the 
test  objectives.  Another  consideration  is  whether  the 
initial  design  goals  are  still  accomplished.  In  this  case 
the  removal  of  the  dependencies  would  result  in  a 
significant  increase  in  the  manual  effort  required  to 
analyze  test  results.  Therefore  the  initial  design  goals 
would  not  be  accomplished. 
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—  A21001A.ADA 

—  CHECK  THAT  THE  BASIC  CHARACTER  SET  IS  ACCEPTED 

—  OUTSIDE  OF  STRING  LITERALS  AND  COMMENTS. 

—  DCB  1/22/80 

WITH  REPORT; 

PROCEDURE  A21001A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED"  ); 
DECLARE 


TYPE  TABLE  IS  ARRAY  (1. .10)  OF  INTEGER; 

A  ;  TABLE  :«  (2  |  4  I  10  ->  1  ,  1  I  3  |  5..9  ->  0  )  ; 

—  USE  OF  ;  (  )  |  , 

TYPE  BUFFER  IS 

RECORD 

'LENGTH  :  INTEGER; 

POS  :  INTEGER; 

IMAGE  :  INTEGER; 

END  RECORD;  —  USED  TO  TEST  .  LATER 

R1  ;  BUFFER; 

ABCDEFGHIJKLM  :  INTEGER;  —  USE  OF  ABCDEFGHIJKLM 

NOPQRSTUVWXYZ  ;  INTEGER;  —  USE  OF  NOPQRSTUWXYZ 

Z_1 234567890  ;  INTEGER;  —  USE  OF  _1234567890 

II,  12,  13  :  INTEGER; 

Cl,  C2  ;  STRING  (1..6); 

C3  :  STRING  (1..12); 

BEGIN 

II  j-  2  *  (  3  -  1  +  2  )  /  2  ;  12  8  ;  —  USES  ()*+-/; 


Cl  "ABCDEF"  ; 
C2  Cl; 

C3  Cl  &  C2  ; 

12  16#D#; 

13  A’LAST; 
Rl.POS  3; 

IF  II  >  2  AND 

II  -  4  AND 
II  <  8  THEN 
NULL; 

END  IF; 

END; 

RESULT; 

END  A21001A: 


—  USE  OF  " 

—  USE  OF  & 

—  USE  OF  # 

—  USE  OF  * 

—  USE  OF  . 


—  USE  OF  >  -  < 
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The  next  step  is  to  look  for  a  way  the  tests  can  be 
constructed  without  the  language-feature  dependencies.  The 
problem  is  that  there  is  a  need  for  the  capability  to  report 
test  status,  therefore  there  will  always  be  language-feature 
dependencies.  Since  the  dependencies  cannot  be  completely 
eliminated,  emphasis  should  be  placed  on  developing  a  method 
for  reporting  the  status  using  language  features  likely  to 
be  supported  early  in  a  compiler's  development.  Special 
emphasis  must  be  placed  on  eliminating  the  need-^for  separate 
compilation,  since  it  is  usually  not  implemented  "im  the 
early  stages  of  a  compiler  development  effort. 


procedure  aample^test  is 
procedure  test  is 
begin 

—  code 
end; 

procedure  result; 
begin 

—  code 
end; 

begin 

test; 

—  code 
result; 
end; 

Figure  2-4 .  Repackaged  Structure  for  Class  A  tests 


There  are  several  ways  the  test  set  could  be  repackaged 
to  reduce  the  language  dependencies.  Perhaps  the  simplest 
method  is  to  insert  the  TEST  and  RESULT  procedures  into  the 
actual  test  in  the  manner  shown  in  figure  2-4. 
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This  method  would  require  the  insertion  of  two 
procedures  in  the  test  and  the  elimination  of  the  WITH  and 
USE  statements.  Also  the  manner  in  which  input/output  is 
handled  must  be  considered  since  the  TEST  and  RESULT 
procedures  require  some  means  of  input /output .  In  the  REPORT 
package  the  dependency  on  TEXT_IO  is  declared.  The  manner  in 
which  input/output  is  handled  in  evolving  compilers  varies 
greatly,  so  the  actual  code  for  the  TEST  and  FAIL  procedures 
will  probably  need  to  be  rewritten  for  each  compiler  being 
tested . 

The  final  question  considered  is  whether  Class  A  tests 
could  be  used  to  test  evolving  compilers  once  the 
language-feature  dependencies  are  removed.  The  answer 
depends  on  what  language  features  are  implemented  by  the 
compiler  being  tested,  and  what  features  are  used  in  the 
tests.  For  instance,  the  test  shown  in  figure  2-3  would 
fail  if  the  compiler  being  tested  did  not  support  the  record 
structure.  This  means  for  Class  A  tests  to  be  usable,  some 
means  for  identifying  language  features  must  exist.  Tests 
that  use  features  not  supported  by  the  compiler  must  either 
be  eliminated  from  the  test  set,  or  the  features  not 
supported  must  be  eliminated  from  the  test.  In  the  case  of 
the  test  in  figure  2-3,  the  type  declaration  of  buffer,  the 
declaration  of  R1  as  type  buffer,  and  the  assignment 
statement  Rl.pos  3  could  be  removed.  The  resulting  test 
could  then  be  used  to  test  evolving  Ada  compilers  which  do 
not  support  records. 
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—  C27001A.ADA 

—  CHECK  THAT  A  COMMENT  IS  TERMINATED  BY  THE  END  OF  THE 

—  LINE,  AND  NOT  BY  THE  NEXT  —  (ELSE  THIS  COMMENT  WILL  BE 

—  TREATED  AS  CODE). 

—  DCB  1/16/80 

WITH  REPORT; 

PROCEDURE  C27C01A  IS 
USE  REPORT; 

II  :  INTEGER; 

BEGIN 

TEST(”C27001A" ,”COWENTS  TERMINATED  BY  END  OF  LINE"); 

II  5;  —  II  INITIALIZED. 

—  BELOW  CHECKS  THAT  A  COMMENT  IS  TERMINATED  BY  END  OF  LINE 
II  II  +  7; 

IF  II  /-  12  THEN 

FAILED( "C0M1ENTS  NOT  TERMINATED  BY  END  OF  LINE"); 
END  IF; 

RESULT; 

END  C27001A; 


Figure  2-5.  Class  C  Test 


2.4.2  Class  C 

Class  C  tests  are  very  similar  to  the  Class  A  tests. 
The  primary  difference  is  that  Class  C  tests  have  a  run-time 
check,  usually  in  the  form  of  an  IF  statement.  Approximately 
65  percent  of  the  tests  in  the  test  set  are  Class  C  tests. 
An  example  of  a  Class  C  test  is  shown  in  Figure  2-5. 

Class  C  tests  contain  the  same  dependencies  found  in 
Class  A  tests.  They  also  have  one  additional  dependency,  the 
procedure  call  FAILED.  The  FAILED  procedure  is  also  found  in 
the  separately  compiled  REPORT  package. 
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The  test  objectives  of  Class  C  tests  will  not  be 
accomplished  if  the  FAILED  procedure  is  removed.  The  FAILED 
procedure  is  an  integral  part  of  the  run-time  check,  and  if 
it  is  removed  the  run-time  check  will  not  be  performed. 
Therefore  it  is  essential  that  some  method  be  developed  for 
repackaging  the  FAILED  package. 

The  method  used  to  repackage  Class  A  tests  can  also  be 
used  for  Class  C  tests.  The  only  major  difference  would  be 
the  inclusion  of  the  FAILED  procedure.  The  repackaged  tests 
would  have  the  form  shown  in  figure  2-6. 


Figure  2-6.  Restructured  Class  C  test 

Class  C  tests  are  similar  to  Class  A  tests  in  that  they 
cannot  be  used  to  test  an  evolving  compiler  unless  all  of 
the  unsupported  features  are  removed  from  the  tests. 
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—  D4A002B.ADA 

—  LARGER  LITERALS  IN  NUMBER  DECLARATIONS,  BUT  WITH  RESULTING 

—  SMALLER  VALUE  OBTAINED  BY  SUBTRACTION.  THIS  TEST  LIMITS 

—  VALUES  TO  64  BINARY  PLACES. 


WITH  REPORT; 

PROCEDURE  D4A002B  IS 
USE  REPORT; 

X  :  CONSTANT  4123456789012345678  -  4123456789012345679; 

Y  :  CONSTANT  4  *  (10  **  18)  -  3999999999999999999; 

Z  :  CONSTANT  (1024  **  6)  -  (2  **  60); 

D  ;  CONSTANT  9  223_372  036_854  775_807 / 20_303_320_287_433 ; 

E  :  CONSTANT  :«  36_028_790_976  242_271  REM  17_600_175_361 ; 

F  :  CONSTANT  :-  (  -2  **  5lJ  MOD  (  -  131JJ71  ); 

BEGIN  TEST("D4A002B", "LARGE?  INTEGER  RANGE  (WITH  CANCELLATION)  IN  "  & 
"NUMBER  DECLARATIONS;  LONGEST  INTEGER  IS  64  BITS  "); 

IF  X  /-  -1  OR  Y  /-  1  OR  Z  /-  0 

OR  D  /-  454_279  OR  E  /-  1  OR  F  /-  -1 
THEN  FAILED( "EXPRESSIONS  WITH  A  LARGE  INTEGER  RANGE  (WITH  "•  & 
"CANCELLATION)  ARE  NOT  EXACT  "); 

END  IF; 

RESULT; 

END  D4A002B; 


Figure  2-7.  Class  D  Test 


2.4.3  Class  D 

Class  D  capacity  tests  make  up  less  than  one  percent  of 
the  tests  in  the  test  set.  They  have  the  same  structure  as 
the  Class  C  tests,  and  they  contain  the  same  dependencies. 
Figure  2-7  shows  a  typical  Class  D  test.  Class  D  tests 
should  be  repackaged  in  the  same  manner  as  the  Class  C 
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—  B32A06A .ADA 

—  CHECK  THAT  IDENTIFIERS  IN  SEPARATE  OBJECT  DECLARATIONS 

—  WITH  IDENTICAL  ARR AY_TYPE_DEFINITIONS  ARE  DIFFERENT 

—  TYPES. 

—  DAT  3/17/81 

PROCEDURE  B32A06A  IS 

A  :  ARRAY  (BOOLEAN)  OF  BOOLEAN; 

B  :  ARRAY  (BOOLEAN)  OF  BOOLEAN; 

BEGIN 


A  :  ■  B ; 

—  ERROR: 

TYPE 

MISMATCH 

A  (TRUE,  TRUE); 

—  OK. 

IF  A  -  B  THEN 

—  ERROR: 

TYPE 

MISMATCH 

NULL ; 

END  IF; 

END  B32A06A; 


Figure  2-8.  Class  B  Test 


2.4.4  Class  £ 

As  mentioned  before.  Class  B  tests  are  designed  to  fail 
compilation.  They  make  up  approximtely  25  percent  of  the 
tests.  A  typical  Class  B  test  is  shown  in  Figure  2-5. 

The  review  of  Class  B  tests  did  not  identify  any 
language-feature  dependencies.  Class  B  tests  do  not  use  the 
REPORT  package.  Unlike  Class  A  and  Class  C  tests,  the  Class 
B  tests  do  not  require  that  unsupported  features  be  removed 
from  tests.  Class  B  tests  should  still  fail  in  any 
implementation . 
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2.4.5  Class  JL 

|  The  Class  L  tests  were  designed  to  fail  at  link  time. 

|  Figure  2-8  shows  a  Class  L  test.  The  Class  L  tests  make  up 

approximately  7  percent  of  the  tests  in  the  test  set. 

These  tests  use  separately  compiled  packages  and  many 
i  of  the  advanced  features  of  the  language.  The  tests  also 

rely  on  other  Class  L  tests  to  accomplish  their  objectives. 
Because  of  the  relationships  that  exist  between  Class  L 
tests,  the  changes  made  in  one  test  may  affect  several  other 
tests.  It  is  unlikely  that  evolving  compilers  would  find 
these  tests  useful.  Because  of  the  relationships  that  exist 
between  these  tests  and  their  limited  usefulness  during 
|  compiler  development,  no  attempt  will  be  made  to  repackage 

1  these  tests. 
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2.4.6  Class  E 


There  are  no  examples  of  class  E  tests  in  the  version 
of  the  ACVC  being  studied,  therefore  no  analysis  of  a  Class 
E  test  was  made. 

2 . 5  Summary 

The  analysis  of  the  ACVC  test  set  revealed  that  several 
language-feature  dependencies  existed  in  the  test  set.  These 
dependencies  could  not  be  totally  eliminated,  but  it  was 
possible  to  repackage  the  tests  to  minimize  the  impact  of 
the  dependencies.  The  analysis  also  revealed  that  the 
elimination  of  dependencies  is  not  enough  to  produce  a  test 
set  which  can  be  used  to  test  subset  compilers. 

In  addition  to  repackaging  the  tests,  some  method  for 
removing  unsupported  language  features  is  needed  for  Class 
A,  Class  C,  and  Class  D  tests.  Once  these  unsupported 
features  are  removed,  the  Class  A,  Class  C,  and  Class  D 
tests  could  be  combined  with  the  Class  B  tests  to  make  a 
viable  test  set. 
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3.  PROJECT  DEVELOPMENT 


3 . 1  Introduction 

This  chapter  describes  the  development  of  an  automated 
tool  designed  to  remove  unsupported  language-features  from 
tests  contained  in  the  ACVC  test  set.  The  description  begins 
with  a  brief  overview  of  the  development  process.  This  is 
followed  by  three  sections  which  describe  the  development  of 
the  tool's  major  components.  The  final  section  summarizes 
the  development  process. 

3 . 2  Overview 

The  analysis  presented  in  chapter  2  concluded  that 
Class  A,  Class  C  and  Class  D  tests  must  be  modified  before 
they  can  be  used  to  test  evolving  Ada  compilers.  The 
analysis  identified  two  modifications  that  must  take  place, 
the  elimination  of  language-feature  dependencies  and  the 
removal  of  langauge  features  not  supported  in  the  compiler 
being  tested. 

The  removal  of  language-feature  dependencies  was 
discussed  in  chapter  2.  It  requires  the  recoding  of  three 
procedures  contained  in  the  separately  compiled  REPORT 
package.  These  recoded  procedures  must  be  inserted  in  the 
test  programs. 

The  removal  of  unsupported  features  from  the  test  set 
is  a  more  difficult  task.  The  fundamental  system  model  of 
the  process  required  to  accomplish  the  task  is  illustrated 
in  figure  3-1. 
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The  modification  of  the  test  program  shown  in  figure 
3-1  can  be  broken  into  three  steps  (Figure  3-2).  The  first 
step  takes  the  test  program  as  input  and  produces  the 
productions  and  any  identifiers,  characters,  numbers  and 
strings  as  output.  The  second  step  uses  the  output  from  the 
first  step  to  build  a  representation  of  the  test  program. 
The  third  step  takes  the  representation  and  the  list  of 
unsupported  features  as  input,  and  produces  a  modified 
program  as  output. 
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Figure  3-2.  Internal  structure  of  Modify  Test  Program 

3 . 3  Identification  of  language -features 

One  of  the  problems  encountered  during  the  analysis 
phase  was  the  need  to  identify  the  language-features  used  in 
the  ACVC  tests.  Initially  the  identification  was  done 
manually  using  the  BNF  contained  in  the  "Ada  Reference 
Manual".  In  this  approach,  a  matrix  was  produced  that 
represented  the  tests  contained  in  the  test  set  and  the 
language-features  used  in  each  of  the  tests.  Once  a  compiler 
was  identified  for  testing,  the  matrix  would  be  used  to 
identify  tests  which  contained  features  not  supported  by  the 
compiler.  These  tests  would  then  be  removed  from  the  test 
set.  This  approach  was  abandoned  for  two  principle  reasons: 
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(1)  The  analysis  indicated  that  tests  containing 
unsupported  language  features  could  still  be  used  if 
the  unsupported  features  were  removed  (Appendix  D 
contains  an  example). 

(2)  The  amount  of  effort  required  to  generate  the 
matrix  manually  was  unreasonable  (Appendix  E  contains 
an  example  of  a  manual  evaluation  of  a  test). 

The  results  of  the  first  approach  made  it  clear  that 
any  process  developed  to  modify  the  test  set  would  have  to 
be  completely  automated  to  be  of  any  value.  Any  process 
which  required  manual  evaluation  of  the  tests  would  take  too 
much  effort. 

If  the  process  for  modifying  tests  was  to  be  automated, 
the  first  step  would  still  require  the  identification  of  the 
language-features  used  in  the  test  set.  Since  the  manual 
evaluation  was  essentially  the  same  process  performed  by  a 
parser,  the  possibility  of  using  an  existing  parser  was 
investigated.  This  investigation  led  to  the  selection  of 
the  parser  used  in  a  compiler  developed  by  Alan  R. 
Garlington  (Ref  5)  for  use  in  the  project  (Appendix  F 
describes  Garlington's  compiler). 

The  parser  used  in  Garlington's  compiler  was  selected 
for  two  primary  reasons.  The  first  reason  was  that  it 
parsed  the  entire  Ada  language  proposed  in  the  1980  version 
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of  the  LRM,  which  meant  it  should  be  capable  of  parsing  all 
the  tests  in  the  ACVC  test  set.  The  second  reason  was  that 
it  was  available  in  source  code.  This  meant  that  it  would  be 
possible  to  modify  the  output  from  the  parser  based  on  the 
needs  of  the  tool.  An  additional  advantage  was  that  the 
Garlington  compiler  was  an  evolving  compiler  and  a  potential 
candidate  for  testing.  The  Garlington  compiler  resided  on 
the  DEC-10  computer  located  at  the  Air  Force  Wright  Avionics 
Laboratory.  The  decision  was  made  to  transport  the 
Garlington  compiler  onto  the  VAX  11-780  at  the  Air  Force 
Institute  of  Technology,  where  several  other  ongoing  Ada 
efforts  were  residing.  Appendix  G  describes  the  changes 
made  to  the  Garlington  compiler  in  order  to  get  it  to 
compile  on  the  Vax  11-780. 

Once  the  compiler  was  transported  onto  the  VAX  11-780, 
efforts  were  then  directed  toward  finding  a  method  for 
outputting  the  language-features  identified  by  the  parser. 
The  Garlington  compiler  has  a  switch  (traceparse)  which 
enables  the  output  of  productions  used  by  the  program,  along 
with  some  other  information.  By  modifying  some  write 
statements  it  was  possible  to  output  the  valid  productions. 
The  only  other  output  required  from  the  compiler  was  the 
identifiers,  characters,  strings  and  numbers  identified. 
Although  it  was  determined  this  information  could  be 
extracted  from  the  parser  the  effort  did  not  go  beyond 
identifying  the  form  of  the  output. 
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The  format  for  the  output  from  the  parser  is  as 
follows : 

production  3 
id  —  aname 
string  ■  "abcde" 
number  ■  1234 
char  *  '  a  ' 

The  are  two  reasons  the  efforts  in  the  area  of  the 
parser  were  limited.  First,  changes  made  in  the  LRM  meant 
the  BNF  used  in  Garlington's  compiler  (Appendix  C  contains 
the  BNF  used  in  Garlington’s  compiler)  no  longer  complied 
with  the  Ada  standard.  Before  a  finished  product  could  be 
developed  a  new  parser  would  be  needed.  Second,  the  primary 
purpose  of  this  thesis  was  to  develop  methods  for 
repackaging  ACVC  tests  so  they  could  be  used  for  testing 
evolving  compilers.  Therefore,  the  primary  emphasis  was 
placed  on  developing  the  process  for  modifying  tests  rather 
than  on  the  modification  of  an  existing  parser.  As  the 
language  continues  to  evolve  the  number  of  parsers  available 
should  increase. 

3 . 4  Development  of  £  representation 

Before  any  modifications  to  a  test  program  can  be  made 
some  method  of  representing  the  program  is  required.  A 
commonly  used  representation  is  a  parse  tree  (Figure  3-3 
shows  the  structure  of  a  typical  parse  tree).  The  parse  tree 
structure  shown  in  figure  3-3  was  considered,  but  it  was  not 
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used  in  this  project.  The  structure  used  is  shown  in  figure 
3-4.  It  was  selected  because  it  would  allow  the  use  of  well 
known  binary  tree  traversal  routines.  It  was  also  selected 
because  it  more  accurately  portrays  the  relationship  between 
siblings,  which  becomes  very  important  when  it  is  necessary 
to  remove  langauge  features  from  the  tree. 
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The  development  of  the  representation  can  be  broken 
into  three  steps.  The  first  step  reads  the  input  file  and 
creates  separate  lists  to  hold  productions,  identifiers, 
characters,  strings  and  numbers.  The  input  type  is  then 
identified  and  inserted  at  the  head  of  the  appropriate  list. 

The  second  step  takes  the  production  number  from  the 
head  of  the  production  list  and  builds  a  representation  of 
the  production.  This  representation  must  contain  the 
production  name  and  the  production  number.  The  parent  node 
is  given  its  actual  production  number,  while  its  children 
are  initialized  to  0.  Figure  3-5  shows  what  the  structure 
would  look  like  if  the  first  production  number  was  3.  The 
production  number  is  shown  in  the  upper  left  corner  of  each 
box.  Nodes  which  contain  printable  tokens  are  identified 
with  a  'P'  in  the  lower  right  corner  of  the  box. 

The  final  step  inserts  the  representation  developed  in 
the  tree.  This  is  accomplished  using  a  post-order  traversal 
beginning  with  the  right  (sibling)  branch.  The  traversal 
searches  the  tree  for  a  production  name  matching  the  one  to 
be  inserted.  If  a  match  is  found  the  production  number  is 
checked.  If  the  production  number  is  0  the  representation  is 
inserted,  otherwise  the  search  is  continued.  This  check  is 
necessary  since  the  same  production  name  may  appear  several 
places  in  the  tree.  This  process  is  repeated  until  all 
productions  have  been  inserted  in  the  tree.  Figure  3-6  shows 
what  the  tree  would  look  like  if  the  second  production 
number  was  A,  and  it  was  Inserted  in  the  tree. 
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3 . 5  Removal  of  unsupported  features 

Once  the  representation  of  the  test  program  is  built, 
the  next  step  is  to  remove  the  unsupported  features  from  it. 
At  first  it  appeared  this  could  be  accomplished  by 
traversing  the  tree  and  cutting  unsupported  productions  by 
setting  pointers  to  NIL.  A  close  look  at  sample 
representations  showed  this  was  not  the  case.  There  were  two 
types  of  productions  which  required  special  treatment.  The 
first  type  was  the  recursively  defined  productions  (Appendix 
I),  while  the  second  type  was  the  empty  productions 

(Appendix  H). 

The  most  commonly  encountered  example  of  a  recursive 
production  is  the  statement__list . 

206.  statement_list  statement_list  statement  ; 

Figure  3-7  shows  an  example  of  a  tree  representation 
which  contains  a  statement_list  production.  If  the  compiler 
being  tested  does  not  support  the  NULL  statement,  the 
pointer  to  the  NULL  statement  would  be  set  to  NIL.  The  tree 
left  remaining  is  not  a  valid  representation  of  an  Ada 

program.  For  example,  there  could  be  a  label  left  hanging  on 
the  tree.  That  means  that  the  pointer  labelled  D  must  also 
be  set  to  NIL.  Another  problem  is  that  the  comma  following 

the  statement  is  still  left  on  the  tree.  Since  the  statement 

has  been  eliminated,  the  comma  must  also  be  removed.  By 
setting  the  pointer  labelled  E  to  NIL,  the  comma  would  be 
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Figure  3-7.  Representation  of  a  recursive  production 
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eliminated.  While  this  completes  the  removal  of  the 
printable  tokens  which  would  be  illegal  in  a  program,  it 
does  not  leave  a  valid  tree.  There  are  still  nodes  which 
should  be  removed.  The  statement  node  no  longer  belongs  in 
the  tree.  To  produce  a  valid  representation  requires  setting 
the  pointer  labelled  C  (Figure  3-7)  to  NIL.  It  also  requires 
that  the  pointer  labelled  A  must  be  set  equal  to  the  pointer 
labelled  B. 

A  slightly  different  case  arises  if  the  statement 
pointed  to  by  the  B  pointer  is  not  supported.  The  recursive 
traversal  used  would  set  the  pointer  C  to  NIL  before  the 
pointer  to  A  is  set  equal  to  C.  Therefore  it  is  necessary  to 
mark  the  descendant  of  any  potentially  recursive  production. 
This  stops  the  traversal  before  valid  statements  are 
eliminate  J . 

The  second  type  of  productions  encountered  can  be 
classified  as  empty  productions  (production  284  is  an 
example).  They  are  productions  which  contain  no  data  in 
their  children.  Empty  productions  occur  where  the  inclusion 
of  information  is  optional  in  a  program.  The  problem  is 
identifying  those  instances  where  data  is  optional. 
Production  285  is  an  example  of  such  a  case.  Designators  may 
be  included  in  programs,  but  there  is  no  requirement  for 
them.  If  they  are  removed  from  the  program  the  remaining 
program  is  still  valid. 

284.  designator_option  — empty 

285.  designator_ option  designator 
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Figure  3-8.  Representation  of  a  potentially  empty  production 


Figure  3-9.  Representation  after  production  is  eliminated 


Figure  3-8  shows  an  example  of  a  structure  using  a 
production  which  is  potentially  empty.  If  production  285  was 
not  supported  by  the  compiler  being  tested,  the  only  action 
required  is  to  remove  the  data  in  the  representation  pointed 
to  by  its  child  pointer.  In  the  representation  shown  in 
figure  3-8,  the  designator  representation  would  appear  as  an 
empty  box  after  the  appropriate  action  was  taken  (figure  3-9 
shows  what  the  modified  representation  would  look  like).  The 
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important  fact  to  remember  when  eliminating  the  potentially 
empty  productions  is  that  the  impact  is  localized.  No 
changes  are  required  at  a  higher  level  in  the  tree  than 
where  the  empty  node  is. 

3.5.1  Outputting  the  modified  representation 

After  the  unsupported  features  have  been  removed  from 
the  tree,  the  final  step  is  to  output  the  information 
contained  in  the  remaining  tree.  This  tree  should  represent 
a  valid  Ada  program  which  can  be  submitted  to  the  evolving 
compiler  being  tested. 

Outputting  the  remaining  representation  is  accomplished 
by  traversing  the  tree  in  an  in-order  fashion  beginning  with 
the  left  (son)  branch.  Nodes  in  the  tree  which  contain 
tokens  that  should  be  printed  have  the  boolean  variable 
PRINTABLE  set  to  true.  This  was  done  in  the  record  when  the 
structure  was  being  built. 

3 . 6  Summary 

The  development  of  the  project  addressed  several 
factors  which  must  be  considered  when  developing  a  tool  to 
remove  unsupported  language-features.  These  included  the 
specification  of  the  input  format,  the  method  of 
representing  the  program,  the  different  classes  of 
productions  which  can  be  removed  from  the  tree,  and  the 
method  for  outputting  the  modified  tree.  The  next  chapter 
will  describe  the  tool  actually  developed  and  its 
capabilities . 
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4 . 1  Introduction 

Chapter  three  discussed  the  development  of  a  tool  which 
removes  unsupported  language-features  from  the  test  set. 
This  chapter  will  discuss  the  actual  implementation  of  the 
tool.  It  will  describe  the  input  required,  the  data 
structure  used  to  represent  the  productions,  the  output  from 
the  tool,  and  the  limitations  on  the  use  of  the  tool. 

4 . 2  Input 

The  fundamental  system  model  illustrated  in  figure  3-1 
requires  a  list  of  unsupported  language-features  and  a  test 
program  as  input.  The  list  of  unsupported  language-features 
must  be  created  by  the  user  and  placed  in  a  file  named 
BADPRODS.  In  the  current  implementation  the  test  program  is 
submitted  to  the  parser  using  the  following  command 
sequence : 

px  work.p  <  f i  lename_of_test__program 

The  fundamental  system  model  also  shows  productions, 
characters,  strings,  identifiers,  and  numbers  as  output  from 
the  parser  and  input  to  the  tool.  This  input  requires  some 
manual  preparation  in  the  current  implementation.  This  is  a 
result  of  not  having  an  adequate  parser  to  work  with.  The 
format  for  the  input  was  shown  in  chapter  three.  Productions 
are  submitted  in  the  order  they  are  output  from  the  parser. 
Identifiers,  numbers,  characters,  and  strings  should  be 


placed  in  the  same  order  they  occurred  in  the  program.  Once 
this  file  is  prepared  it  is  submitted  to  the  tool  using  the 
following  command: 

px  tree.p  <  infile 
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4 . 3  Data  Structures 

This  section  will  describe  the  data  structure  used  to 
represent  the  productions  contained  in  the  BNF .  The  data 
structure  used  is  shown  in  figure  4-1.  The  fields  in  the 
record  structure  are  used  as  follows: 

DATA  -  contains  the  name  of  the  production. 

NUM  -  contains  the  production  number  (Appendix  C). 
SIBLING  -  points  to  a  sibling, 

SON  -  points  to  the  sen  (child). 

PARENTPTR  -  points  to  the  parent.  This  pointer  is  not 
currently  being  used.  It  can  be  connected  by  modifying 
the  INSERTPRODUCTION  procedure. 

PRINTABLE  -  boolean  used  to  identify  the  data  in  a  node 
that  should  be  output. 

NEWLINE  -  boolean  used'  for  formatting  purposes. 
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INDENT  -  boolean  used  for  formatting  purposes. 
RECDESCENDANT  -  boolean  used  to  identify  a  node  as  the 
son  of  a  recursive  production. 

CUTNODE  -  boolean  used  to  identify  nodes  which  contain 
unsupported  language  features. 


Figure  4-1.  Data  structure  used  to  represent  productions 


The  actual  representation  is  generated  by  means  of  a 
large  case  statement.  The  case  statement  creates  nodes 
containing  the  information  shown  in  figure  4-1  for  each 
production  found  in  the  BNF.  The  DATA  field  for  characters, 
strings,  numbers,  and  identifiers  is  filled  by  taking  the 
top  element  from  the  corresponding  list  created  by  the 
parser.  The  RECDESCENDANT  and  CUTNODE  fields  are  initialized 
false  and  then  updated  during  the  traversal  of  the  tree  by 
checking  the  BADPRODS  and  RECURSI VEPRODS  lists. 


4 . 4  Output 

There  are  two  options  available  for  output.  They  are 
controlled  by  switches  which  are  initialized  in  the 
INITGLOBALS  procedure.  The  first  switch  is  FULLTREE,  which 
if  set  TRUE  prints  out  the  entire  tree  (minus  comments). 
This  option  was  provided  primarily  for  testing  purposes  and 
would  not  normally  be  set  TRUE.  The  second  switch  is 
CUTTREE ,  which  if  set  TRUE  will  print  out  the  modified 
version  of  the  tree.  All  output  is  written  to  a  file  named 
OUTF. 

Figures  4-2,  4-3  and  4-4  illustrate  how  the  output  from 
the  tool  should  change  as  features  are  added  to  the  compiler 
being  tested.  Fig  4-2  shows  what  a  test  should  look  like  for 
a  compiler  which  does  not  support  arrays  and  records.  Figure 
4-3  shows  what  the  new  version  of  the  test  should  look  like 
after  arrays  are  implemented.  Figure  4-4  shows  what  the 
test  should  look  like  after  records  and  arrays  are  both 
implemented . 

4 . 5  Limitations 

The  current  implementation  has  some  limitations  which 
the  user  should  be  aware  of.  Perhaps  the  most  serious  is  the 
limitation  imposed  by  the  specific  BNF  used  to  develop  the 
parser.  It  makes  it  difficult  to  identify  and  eliminate 
unsupported  data  types.  For  example,  if  integers  were  not 
supported,  the  BNF  provides  no  way  of  determining  whether  a 
type  is  integer  or  real.  The  current  BNF  uses  the  following 
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productions  to  represent  an  integer: 

subtype_indication  name 

literal  number 

There  are  two  ways  to  overcome  this  problem.  The  first 
is  by  outputting  more  detailed  information  from  the  symbol 
table.  The  second  and  probably  easier  way  is  to  use  an 
extended  form  of  the  BNF  which  is  more  descriptive.  The 
following  extensions  were  made  to  the  BNF  to  demonstrate 
types  could  be  cut  from  the  representation  along  with 
occurrences  of  the  types  in  the  program  body. 

subtype_indication  integer 

literal  integer__number 

integer_number  number 

These  extensions  would  be  necessary  for  other  data 
types  as  well.  There  is  one  problem  not  solved  by  the 
extensions,  and  that  is  the  scope  of  the  variables.  This 
information  would  need  to  be  obtained  from  the  symbol  table 
and  stored  in  the  record  structure. 

The  process  developed  to  modify  the  tests  also  imposes 
some  inherent  limitations.  Modifications  are  based  on 
syntactic  issues  and  do  not  take  into  consideration  the 
semantic  rules  being  tested.  No  provisions  are  made  in  the 
test  set  to  account  for  the  semantic  rules  that  an  evolving 
compiler  may  not  have  implemented.  An  example  of  this  would 
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WITH  REPORT; 

PROCEDURE  A21001A  IS 

USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED"  ); 

DECURE 

ABCDEFGHIJKLM  ;  INTEGER 

—  USE  OF  ABCDEFGHIJKIH 

NOPQRSTUWXYZ  :  INTEGER 

—  USE  OF  NOPQRSTUVWXYZ 

Z  1234567890  :  INTEGER 

—  USE  OF  1234567890 

11,  12,  13  :  INTEGER; 

Cl,  C2  :  STRING  (1..6); 
C3  ;  STRING  (1. .12); 
BEGIN 

11  2  *  (  3  -  1  +  2  ) 

/  2  ;  12  :«  8  ;  —  USES  ()*  +  -/; 

Cl  ;»  "ABCDEF”  ; 

—  USE  OF  ” 

C2  Cl; 

C3  Cl  &  C2  ; 

—  USE  OF  & 

12  16#D#; 

—  USE  OF  # 

IF  11  >  2  AND 

11  -  4  AND 

11  <  8  THEN 

—  USE  OF  >  -  < 

NULL; 

END  IF; 

END; 

RESULT; 

END  A21001A; 

Figure  4-2.  Test  with  records  and  arrays  removed 


be  the  length  of  identifiers  allowed  in  the  compiler  being 
tested.  The  language  definition  allows  identifiers  to  be  as 
long  as  the  maximum  input  line  length  permitted  by  the 
implementation.  All  characters  in  the  identifier  are 
significant.  If  the  compiler  developer  chose  to  make  only 
the  first  eight  characters  significant,  no  method  is 
provided  to  modify  the  test  set  accordingly.  It  could  be 
accomplished  by  generating  shorter  names  for  the  identifiers 
found  in  the  symbol  table.  This  would  make  comparisons 
between  the  ACVC  tests  and  the  modified  tests  difficult. 
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WITH  REPORT; 

PROCEDURE  A21001A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED”  ); 
DECLARE 


TYPE  TABLE  IS  ARRAY  (1..10)  OF  INTEGER; 

A  :  TABLE  :«  (2  I  4  |  10  ->  1  ,  1  I  3  I  5. .9  »>  0  )  ; 

—  USE  OF  :  (  )  I  , 


ABCDEFGHIJKLM  :  INTEGER; 
NOPQRSTUVWXYZ  :  INTEGER; 
Z_1234567890  :  INTEGER; 
II,  12,  13  ;  INTEGER; 

Cl,  C2  :  STRING  (1..6); 
C3  ;  STRING  (1. .12); 


—  USE  OF  ABCDEFGHIJKLM 

—  USE  OF  NOPQRSTUVWXYZ 

—  USE  OF  1234567890 


BEGIN 


2*(3-l+2)/2;I2;»8;  —  USES  ()*+-/; 


Cl  "ABCDEF"  ; 

C2  Cl; 

C3  Cl  &  C2  ; 

12  16#D#; 

13  A 'LAST; 

IF  II  >  2  AND 

II  -  4  AND 
II  <  8  THEN 
NULL; 

END  IF; 

END; 

RESULT; 

END  A21001A; 


—  USE  OF  " 

—  USE  OF  & 

—  USE  OF  # 

—  USE  OF  ' 


—  USE  OF  >  -  < 
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WITH  REPORT; 

PROCEDURE  A21001A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED"  ) 


DECURE 

TYPE  TABLE  IS  ARRAY  (I. .10)  OF  INTEGER; 

A  ;  TABLE  :«  (2  |  4  |  10  ->  1  ,  1  |  3  {  5..9  ->  0  ) 

—  USE  OF  :  (  )  |  , 


TYPE  BUFFER  IS 

RECORD 

LENGTH  :  INTEGER; 

POS  :  INTEGER; 

IMAGE  :  INTEGER; 

END  RECORD;  —  USED  TO  TEST  . 

R1  j  BUFFER- 


I 


UTER 


ABCDEFGHIJKLM  ;  INTEGER; 
NOPQRSTUVWXYZ  :  INTEGER; 
3_1 234567890  :  INTEGER; 
II,  12,  13  :  INTEGER; 


—  USE  OF  ABCDEFGHIJKLM 

—  USE  OF  NOPQRSTUVWXYZ 

—  USE  OF  1234567890 


Cl,  C2  :  STRING  (1..6); 
C3  :  STRING  (1..12); 


BEGIN 


11 

2  *  (  3  -  1  +  2  ) 

/  2  ;  12  ; 

8  ;  —  USES  (  )  *  + 

Cl 

;■ 

"ABCDEF"  ; 

—  USE 

OF 

tf 

C2 

Cl; 

C3 

:■ 

Cl  &  C2  ; 

—  USE 

OF 

& 

12 

:■ 

16#D#; 

—  USE 

OF 

# 

13 

;■ 

A'LAST; 

—  USE 

OF 

9 

Rl. 

,POS  s-  3; 

—  USE 

OF 

• 

IF 

11 

>  2  AND 

11 

-  4  AND 

11 

<  8  THEN 

—  USE 

OF 

>  -  < 

NULL; 
END  IF; 
END; 

RESULT; 

END  A21001A; 


Figure  4-4.  Coaplete  test 
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5.  RECOMMENDATIONS  AND  CONCLUSIONS 

5 . 1  Introduction 

This  chapter  describes  areas  where  follow-on 
could  begin  and  where  deficiencies  in  the 
implementation  exist.  It  also  discusses  conclusions 
about  the  feasibility  of  using  the  modified  test  set 
evolving  Ada  compilers. 

5 . 2  Recommendations 

There  are  several  deficiencies  in  the  current 
implementation  which  should  be  corrected  before  the  tool  is 
used  to  produce  a  valid  test  set.  The  most  critical 
deficiency  is  the  lack  of  an  adequate  parser.  A  parser 
needs  to  be  developed  using  the  current  langauge  description 
and  any  extensions  that  will  allow  a  complete  identification 
of  the  language-features  used  in  the  test  set.  This  parser 


could 

possibly  be 

built 

using 

LEX 

and 

YACC 

facilities 

provided  on  the  VAX 

11-780. 

The 

LEX 

and 

YACC 

facilities 

could 

conceivably 

be  used 

to 

actually 

build 

the  tree 

representation . 

The  development  of  a  new  parser  using  a  different  BNF 
will  require  a  new  case  statement  to  generate  the  data 
structures.  It  is  recommended  that  a  program  be  written  to 
automatically  generate  the  case  statement.  This  program 
should  be  able  to  generate  the  case  statement  using  the  BNF 
as  input. 


efforts 
current 
reached 
to  test 


53 


Once  the  parser  is  developed  some  method  for  keeping 
track  of  the  scope  of  variables  is  needed.  This  problem  may 
require  storing  symbol  table  information  in  the  record 
structures  used  to  represent  the  productions. 

Another  problem  which  needs  to  be  addressed  is  the 
development  of  a  method  for  automatically  repackaging  the 
tests.  The  will  require  either  automating  a  text  editing 
process  or  the  use  of  some  type  of  include  command  in  the 
test  skeleton  developed. 

Also,  a  driver  needs  to  be  written  which  will  take  the 
tests  from  the  test  set  and  feed  them  into  the  parser.  It 
must  then  take  the  output  from  the  parser  and  feed  it  to  the 
tool  implemented.  The  output  from  the  tool  must  be 
concatenated  with  the  other  modified  tests.  The  driver  must 
be  capable  of  identifying  the  test  class  by  reading  the  test 
name.  The  user  may  consider  doing  this  prior  to  submitting 
the  tests. 

Finally,  the  tool  needs  to  be  tested  extensively. 
Because  of  the  amount  of  time  required  to  generate  test 
cases  by  hand,  the  tool  has  not  been  thoroughly  tested. 

5.3  Conclusions 

There  were  a  couple  of  conclusions  reached  while 
working  on  this  project  concerning  the  quality  of  the  ACVC 
and  the  value  of  a  testing  capability  for  evolving 
compilers.  One  conclusion  was  that  the  coding  standards 
used  by  SofTech  were  very  helpful  when  it  became  necessary 
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to  analyze  the  tests.  In  most  cases  they  used  only  the 
minimum  amount  of  features  needed  to  accomplish  the  test 
objectives.  It  appeared  to  be  a  well  organized  testing 
effort  and  should  serve  as  an  example  for  others  to  follow. 
Other  compiler  validation  efforts  studied  were  not  nearly  as 
well  put  together. 

The  final  conclusion  reached  was  that  the  subset 
testing  capability  will  be  of  value  to  compiler  developers 
when  it  is  comdeted.  Although  it  would  not  represent  a 
complete  testing  capability,  it  is  a  good  start  to  one.  Also 
when  completely  implemented  it  would  represent  a  very  easy 
method  for  generating  tests.  The  manual  effort  would  be 
minimal . 
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APPENDIX  A 


Evolving  Compiler  Development 


This  appendix  describes  the  development  of  the  evolving 
compilers  the  modified  test  set  is  targeted  to  test.  It  also 
provides  a  description  of  a  typical  Ada  compiler  development 
effort. 

The  compilers  the  modified  test  set  is  targeted  to  test 
are  those  which  are  developed  as  subsets.  In  other  words,  a 
subset  of  the  langauge  is  defined  and  the  compiler  is  built 
to  compile  just  the  subset.  Additions  are  then  made  to  the 
subset  to  produce  a  version  closer  to  the  complete  langauge. 
The  development  process  portrayed  below  is  the  type  the  test 
set  is  targeted  for. 


lexical  \ 

parser 

semantic 

code  >  subset  1 


lexical 
prar  ser 
semantic 
code 


> 


subset 


2 


finished  J 


finished  y 
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The  compiler  described  below  is  typical  of  those  targeted  to 
be  tested  by  the  modified  test  set.  It  is  the  Ada/1000 
Compiler  developed  by  Science  Applications,  Inc.  This 
information  was  taken  from  a  Science  Applications,  Inc. 
advertisement . 

The  Ada/1000  compiler  is  scheduled  to  consist  of  four 
releases.  The  first  release  will  support  the  following 
features: 

1.  Integer  objects  and  operators 

2.  Boolean  objects  and  operators 

3.  Nested  procedures  and  functions 

4.  Simple  user  defined  types  (arrays, 
enumeration?,  simple  records) 

5.  Sequential  flow  control  (loop, 
if-then-else ,  case) 

The  second  release  of  the  Ada/1000  will  provide  these 
additional  features  : 

1.  Exception  handling 

2.  Overloading 

3.  Packages  (limited) 

4.  Separate  compilation  (limited) 

5.  Tasking  (limited) 

6.  Attributes  (limited) 

7.  Pragmas  (limited) 

8.  Floating  point  objects  and 
operators  (limited) 
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The  third  release 


following  features 


adds  the 

1.  Variant  records 

2.  Full  packages  with  separate  compilation 

3.  Dynamic  arrays  (character  strings  and 
variants ) 

4.  Representation  specification  (length  and 
enumeration  specification). 

5.  Tasking 

6.  Code  statements 

7.  Derived  types 

The  last  release  will  be  a  validated  Ada/1000  compiler. 
It  will  include  the  following  features: 

1.  Generics 

2.  Fixed  point  objects  and  operators 

3.  Low-level  I/O 


As  mentioned  before,  the  development  of  the  Ada/1000 
compiler  is  typical  of  many  of  the  current  development 
efforts.  The  most  significant  aspect  of  these  efforts  is 
that  separate  compilation  is  not  typically  supported  until 
the  second  or  third  release.  This  means  the  ACVC  test  set  is 
of  little  use.  It  also  means  that  the  Input/Output  package 
will  most  likely  be  non-standard. 
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APPENDIX  B 


Report  Package 


This  appendix  contains  the  report  specification  and  the 
report  body  source  listings  found  in  the  ACVC  test  set  (Ref 
3). 
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REPORT  SPECIFICATION 


—  REPSPEC.ADA 

—  THE  REPORT  PACKAGE  PROVIDES  THE  MECHANISM  FOR  REPORTING  THE  PASS/FAIL 

—  RESULTS  OF  EXECUTABLE  (CLASSES  A,  C,  D,  AND  E)  TESTS. 

—  IT  ALSO  PROVIDES  THE  MECHANISM  FOR  GUARANTEEING  THAT  CERTAIN  VALUES 

—  BECOME  DYNAMIC  (NOT  KNOWN  AT  COMPILE-TIME). 

—  JRK  12/13/79 

—  JRK  6/10/80 

—  JRK  8/6/81 

PACKAGE  REPORT  IS 

—  THE  REPORT  ROUTINES. 


PROCEDURE  TEST 


(  NAME  :  STRING( 1 . .7) ; 
DESCR  :  STRING 


); 


—THIS  ROUTINE  MUST  BE  INVOKED  AT  THE 

—  START  OF  A  TEST,  BEFORE  ANY  OF  THE 

—  OTHER  REPORT  ROUTINES  ARE  INVOKED. 

—  IT  SAVES  THE  TEST  NAME  AND  OUTPUTS  THE 

—  NAME  AND  DESCRIPTION. 

—  TEST  NAME,  E.G.,  "C23001A". 

—  BRIEF  DESCRIPTION  OF  TEST,  E.G., 

—  "UPPER/LOWER  CASE  EQUIVALENCE  IN  "  & 

—  "IDENTIFIERS". 


PROCEDURE  FAILED  —  OUTPUT  A  FAILURE  MESSAGE.  SHOULD  BE 

—  INVOKED  SEPARATELY  TO  REPORT  THE 
—  FAILURE  OF  EACH  SUBTEST  WITHIN  A  TEST. 
(  DESCR  :  STRING  —  BRIEF  DESCRIPTION  OF  WHAT  FAILED. 

—  SHOULD  BE  PHRASED  AS: 

—  "(FAILED  BECAUSE)  ...REASON...". 

); 


PROCEDURE  COMMENT 
(  DESCR  :  STRING 
); 


—  OUTPUT  A  COMMENT  MESSAGE. 

—  THE  MESSAGE. 


PROCEDURE  RESULT;  —  THIS  ROUTINE  MUST  BE  INVOKED  AT  THE 

—  END  OF  A  TEST.  IT  OUTPUTS  A  MESSAGE 
—  INDICATING  WHETHER  THE  TEST  AS  A 
—  WHOLE  HAS  PASSED  OR  FAILED. 


—  THE  DYNAMIC  VALUE  ROUTINES. 

—  EVEN  WITH  STATIC  ARGUMENTS,  THESE  FUNCTIONS  WILL  HAVE  DYNAMIC 

—  RESULTS. 

FUNCTION  IDENT  INT  —  AN  IDENTITY  FUNCTION  FOR  TYPE  INTEGER. 

(  X  :  INTEGER  —  THE  ARGUMENT. 

)  RETURN  INTEGER;  —  X. 
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FUNCTION  IDENT_CHAR 

(  X  :  CHARACTER 
)  RETURN  CHARACTER; 

FUNCTION  IDENT_BOOL 
(  X  ;  BOOLEAN 
)  RETURN  BOOLEAN; 

FUNCTION  IDENT_STR 
(  X  :  STRING 
)  RETURN  STRING; 

FUNCTION  EQUAL 

(  X,  Y  :  INTEGER 
)  RETURN  BOOLEAN; 

END  REPORT; 


—  AN  IDENTITY  FUNCTION  FOR  TYPE 

—  CHARACTER. 

—  THE  ARGUMENT. 

—  X. 

—  AN  IDENTITY  FUNCTION  FOR  TYPE  BOOLEAN. 

—  THE  ARGUMENT. 

—  X. 

—  AN  IDENTITY  FUNCTION  FOR  TYPE  STRING. 

—  THE  ARGUMENT. 

—  X. 

—  A  RECURSIVE  EQUALITY  FUNCTION  FOR  TYPE 

—  INTEGER. 

—  THE  ARGUMENTS. 

—  X  <=  Y. 
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REPORT  BODY 


—  REPBODY.ADA 

—  DCB  04/27/80 

—  JRK  6/10/80 

—  JRK  11/12/80 

—  JRK  8/6/81 

WITH  TEXT__IO ; 

PACKAGE  BODY  REPORT  IS 

USE  TEXT_IO; 

TYPE  STATUS  IS  (PASS,  FAIL); 

TEST_STATUS  :  STATUS  :»  FAIL; 

TEST_NAME  ;  STRING(1..7)  "NO_NAME" ; 

PROCEDURE  PUT  MSG  (MSG  :  STRING)  IS 

—  WRITE  MESSAGE.  LONG  MESSAGES  ARE  FOLDED  (AND  INDENTED). 
MAX  LEN  :  CONSTANT  INTEGER  RANGE  50.. 150  72;  —  MAXIMUM 

"  —  OUTPUT  LINE  LENGTH. 

INDENT  :  CONSTANT  INTEGER  RANGE  0..20  :«  15;  —  AMOUNT  TO 

—  INDENT  CONTINUATION  LINES. 

I  j  INTEGER  :=  0;  —  CURRENT  INDENTATION. 

M  ;  INTEGER  :«  MSG' FIRST;  —  START  OF  MESSAGE  SLICE. 

N  j  INTEGER;  —  END  OF  MESSAGE  SLICE. 


BEGIN 

LOOP 

IF  I  +  (MSG ’ LAST-M+ 1 )  >  MAX_LEN  THEN 
N  M  +  (MAX_LEN-I)  -  1; 

IF  MSG(N)  /«  '  '  THEN 

WHILE  N  >  M  AND  THEN  MSG(N+1)  /-  '  '  LOOP 
N  J-  N  -  1; 

END  LOOP; 

IF  N  <  M  THEN 
N  M  +  (MAX_LEN-I)  -  1; 

END  IF; 

END  IF; 

ELSE  N  MSG' LAST; 

END  IF; 

SET_COL  (I  +  1); 

PUT_LINE  (MSG(M..N)); 

I  INDENT; 

M  N  +  1; 

WHILE  M  <-  MSG’ LAST  AND  THEN  MSG(M)  -  '  '  LOOP 
M  M  +  1; 

END  LOOP; 

EXIT  WHEN  M  >  MSG' LAST; 

END  LOOP; 

END  PUT  MSG; 
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PROCEDURE  TEST  (NAME  :  STRING(1..7);  DESCR  :  STRING)  IS 
BEGIN 

TEST_STATUS  PASS; 

TEST  NAME  NAME; 

PUTjSG  (""); 

PUT_MSG  ("■ -  "  &  TEST_NAME  &  "  "  &  DESCR  & 

END  TEST; 

PROCEDURE  COMMENT  (DESCR  :  STRING)  IS 
BEGIN 

PUT_MSG  ("  -  "  &  TEST_NAME  &  "  "  &  DESCR  &  "."); 

END  COMMENT; 

PROCEDURE  FAILED  (DESCR  :  STRING)  IS 
BEGIN 

TESTJ5TATUS  FAIL; 

PUTJfSG  ("  *  "  &  TEST_NAME  &  "  "  &  DESCR  &  "."); 

END  FAILED; 

PROCEDURE  RESULT  IS 
BEGIN 

IF  TESTJ3TATUS  -  PASS  THEN 

PUT_MSG  (" -  "  &  TEST_NAME  & 

"  PASSED - ."); 

ELSE  PUT_MSG  ("****  '•  &  TEST_NAME  & 

"  FAILED - ."); 

END  IF; 

TEST_STATUS  FAIL; 

TEST_NAME  "NO_NAME" ; 

END  RESULT; 

FUNCTION  IDENTJNT  (X  ;  INTEGER)  RETURN  INTEGER  IS 
BEGIN 

IF  EQUAL  (X,  X)  THEN  —  ALWAYS  EQUAL. 

RETURN  X;  —  ALWAYS  EXECUTED. 

END  IF; 

RETURN  0;  —  NEVER  EXECUTED. 

END  IDENTJNT; 

FUNCTION  IDENT_CHAR  (X  :  CHARACTER)  RETURN  CHARACTER  IS 
BEGIN 

IF  EQUAL  (CHARACTER 'POS(X),  CHARACTER' POS(X))  THEN  —  ALWAYS 

—  EQUAL. 

RETURN  X;  —  ALWAYS  EXECUTED. 

END  IF; 

RETURN  'O';  —  NEVER  EXECUTED. 

END  INDENT_CHAR; 
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FUNCTION  IDENT_BOOL  (X  :  BOOLEAN)  RETURN  BOOLEAN  IS 
BEGIN 

IF  EQUAL  ( BOOLEAN' POS(X) ,  BOOLEAN 'POS(X))  THEN  —ALWAYS 

—  EQUAL. 

RETURN  X;  —  ALWAYS  EXECUTED. 

END  IF; 

RETURN  FALSE; 

END  IDENT_BOOL; 

FUNCTION  IDENT_STR  (X  :  STRING)  RETURN  STRING  IS 
BEGIN 

IF  EQUAL  (X' LENGTH,  X' LENGTH)  THEN  —  ALWAYS  EQUAL. 

RETURN  X;  —  ALWAYS  EXECUTED. 

END  IF; 

RETURN 

END  IDENT_STR; 

FUNCTION  EQUAL  (X,  Y  :  INTEGER)  RETURN  BOOLEAN  IS 
REC  LIMIT  :  CONSTANT  INTEGER  RANGE  1..100  :«  3;  —  RECURSION 
”  —  LIMIT. 

Z  j  BOOLEAN;  —  RESULT. 

BEGIN 

IF  X  <  0  THEN 
IF  Y  <  0  THEN 
Z  :«  EQUAL  C-X,  -Y); 

ELSE  Z  :«  FALSE; 

END  IF; 

ELSIF  X  >  RECLIMIT  THEN 

Z  :«  EQUAL  (REC_LIMIT,  Y-X+REC_LIMIT) ; 

ELSIF  X  >  0  THEN 
Z  :»  EQUAL  (X-l,  Y-l); 

ELSE  Z  j«  Y  .  0; 

END  IF; 

RETURN  Z; 

EXCEPTION 

WHEN  OTHERS  -> 

RETURN  X  -  Y; 

END  EQUAL; 

BEGIN 

NULL; 

END  REPORT; 
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Appendix  C 
BNF 

This  appendix  contains  the  BNF  used  by  Garlington's 
compiler.  Terminals  will  be  represented  by  uppercase 
letters.  Nonterminals  will  be  represented  by  lower  case 
letters . 
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1.  system  goal  symbol  END  program  END 

2.  program 

3.  program  compl_unit_list 

4.  compl_unit__list  compilation__unit  ; 

5.  compl _ unit_list  compl_unit_list  compi lation__unit 

6.  vertical_bar  | 

7.  vertical_bar  ! 

8.  id  : *IDENTIFIER* 

9.  char  :  :*=  *CHAR* 

10.  string  *STRING* 

11.  number  ^NUMBER* 

12.  enumeration_literal  i:«  id 

13.  enumeration__literal  char 

14.  pragma_list_option 

15.  pragma_list__option  pragma_list 

16.  pragma_list  pragma  ; 

17.  pragma__list  pragoa_list  pragma  ; 

18.  pragma  PRAGMA  id  ar  gument__list_option 

19.  argument__list_option 

20.  argument__list_option  (  argument_list  ) 

21.  argument__list  argument 

22.  argument_list  ar gument_list  ,  argument 

23.  argument  expression 

24.  argument  id  ->  expression 

25.  declarative__part 

26.  declarative_part  declaration_list 

27.  dec la rationalist  declarative_item  ; 
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48, 
49  . 
5Uv 
51. 


declaratj.on_J.ist  declarative_item  ; 
object_dec la ration 
number_declaration 
use__clause 
type_declaration 
subt ype_declaration 
exception_declaration 
r enaming_declaration 
pragma 

package_declaration 

subprograro_declaration 

task_declaration 

repr esentation_specif i cat ion 

.aration  identif ier_list  :  constant_option 

subtype_indication  initialization_option 

Laration  id  :  constant_option 

subtype_indication  initialization_option 

.aration  identif ier_list  :  constant_option 

array_type__def  in  it  ion  initialization_option 

Laration  id  :  constant_option 

ar  ray__type_def  in  it  ion  initialization_option 

Laration  identif ier_list  :  CONSTANT 

becomes  expression 

.aration  id  :  CONSTANT  becomes  expression 

-becomes  r:» 
constant__optiuu  !i* 
ronst-arif.  J. n if— CONSTANT 

i  ni  tia.l  i  za  t  ion_opti^n  :  :« 

initialiMt-ion^option  becomes  expression 


28. 

decla 

29. 

dec  la 

30. 

decla 

31 . 

decla 

32. 

decla 

33. 

decla 

34. 

decla 

35. 

decla 

36. 

decla 

37. 

decla 

38. 

decla 

39. 

decla 

40. 

decla 

41. 

ob  jec 

42. 

ob  jec 

43. 

ob  jec 

44. 

ob  jec 

45. 

numbe 

46. 

Hum  be 
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52.  type_declaration  TYPE  id  discriminant_part_option 

IS  type_def inition 

53.  type_declaration  TYPE  id  discriminant_part_option 

54.  discriminant_part_option 

55.  discr  iminant_part__option  (  discriminant_list  ) 

56.  discriminant_list  discriminant_declaration 

57.  discriminant_list  discriminant_list  : 

discriminan  t_d  eclaration 

58.  discr iminant_declaration  identif ier_list  : 

subt ype_indica tion  ini tialization_option 

59.  discriminant_declar ation  id  :  subty pe_indication 

initialization__option 

60.  subtype__indication  name 

61.  subtype_indication  name  constraint 

62.  constraint  :s»  range_constraint 

63.  constraint  accuracy__constraint 

64.  type_definition  enumeration_type_def inition 

65.  type_def inition  range_constraint 

66.  type_def inition  accuracy_constraint 

67.  type_def inition  array_type_def inition 

68.  type_def inition  recor d_ty pe_def inition 

69.  type_def inition  ::■>  access_type__def inition 

70.  type_def inition  deri ved_type_def inition 

71.  type_def inition  pri vate__type_def inition 

72.  subtype_d eclaration  SUBTYPE  id  IS  subtype_indication 

73.  derived_type_def ini tion  NEW  subtype_indication 

74.  range_constraint_option 

75.  range_constraint_/)ption  range_constraint 

76.  range_constraint  RANGE  range 
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77.  range  simple_expr essi on  ..  simple_expression 

78.  enumeration_type_def inition 

(  enumeration_li teral_list  ) 

79.  enumeration_liter al_list  enumeration_literal 

80.  enumeration_literal_list  ::*»  enumeration_literal_list  , 

enumeration_li teral 

81.  accuracy_constraint  ::=  DIGITS  simple_expression 

range_constraint_option 

82.  accuracy_constr aint  ::=  DELTA  simple_expr ession 

rang  e_c  onstrain  t_o  p  t i o  n 

83.  array_type_def inition  ::=  ARRAY  (  index_list  )  OF 

subt  y pe_in dicat ion 

84.  index_list  index 

85.  index_list  index_list  ,  index 

86.  index  name  RANGE  <> 

87.  index  f ull_discrete_range 

88.  index  name 

89.  discrete_range  name  range_constraint_option 

90.  discrete_range  range 

91.  f ull_discrete_range  name  range_constraint 

92.  f ull_discrete_range  range 

93.  component_association  choice_list  *>  expression 

94.  component_association  name  accuracy_constraint 

95.  choice_list  choice 

96.  choice_list  choice_list  vertical_bar  choice 

97.  choice  ::■>  simple_expression 

98.  choice  f ull_discr ete_range 

99.  choice  OTHERS 

100.  record_type  definition  RECORD  component_list 

END  RECORD 
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101.  component_list  ::*» 

102.  component_list  compon_decl_list  var iant_par t_option 

103.  component_list  variant_part 

104.  component_list  NULL  ; 

105.  compon_decl_li st  compon_decl 

106.  compon_decl_list  ::=  compon_decl_list  compon_decl 

107.  compon_decl  ::=  identif ier_list  :  subtype_indication 

initialization_option  ; 

108.  compon_decl  id  :  subtype_indication 

initialization_option  ; 

109.  compon_decl  ::=  identif ier_list  :  ar ray_type_def inition 

initialization_option  ; 

110.  compon_decl  id  :  ar ra y_ty pe_def inition 

initialization_option  ; 

111.  variant_part_option 

112.  variant_j?ar t_option  variant_part 

113.  variant_part  CASE  name  IS  var iant_list__option 

END  CASE  ; 

114.  variant_list_option 

115.  variant_list_opt ion  veriant_list 

116.  variant^list  variant 

117.  variant_list  variant_list  variant 

118.  variant  WHEN  choice_list  ->  component_list 

119.  access_type_def inition  ACCESS  subtype_indication 

120.  id_option 

121.  id_option  id 

122.  identif ier_liat  id  ,  id 

123.  identif ier_list  i dentif ier_list  ,  id 

124.  name_list  name 

125.  name_list  name_list  ,  name 
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126.  name  : : «  id 

127.  name  ::**  indexed_component 

128.  name  selected_component 

129.  name  attribute 

130.  indexed_component  name  generalized_expression_list 

131.  indexed_component  ::=  name  (  ) 

132.  selected_component  ::=  name  .  id 

133.  selected_component  name  .  ALL 

134.  selected_component  name  .  string 

135.  attribute  ::=  name  *  id 

136.  attribute  ::=  name  '  DIGITS 

137.  attribute  name  '  DELTA 

138.  attribute  name  ’  RANGE 

139.  subprogr am_naie  name 

140.  subprogram_name  =  string 

141.  literal  string 

142.  literal  number 

143.  literal  char 

144.  literal  NULL 

145.  expression_option 

146.  expression_option  expression 

147.  generali zed_expression_list  gel_head  ) 

148.  gel_head  l_paren  generalized_expression 

149.  gel_head  gel_head  ,  generali zed_expression 

150.  l_paren  ( 

151.  genera li zed_expr ession  expression 
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152.  generali zed_expression  simple_expression  .. 

s i m  p 1 e_e  xpression 

153.  generali zed_expression  component_association 

154.  generali zed_expression  name  range_constraint 

155.  expression  and_expr ession 

156.  expression  or_e xpression 

157.  expression  xor_expr ession 

158.  expression  and_then_expression 

159.  expression  or_else_expression 

160.  expression  :  : «*  relation 

161.  and_expr ession  relation  AND  relation 

162.  and_expr ession  : : *  and_expression  AND  relation 

163.  or _e xpression  relation  OR  relation 

164.  or_expression  or_expression  OR  relation 

165.  xor__expression  relation  XOR  relation 

166.  xor_expression  xor_expression  XOR  relation 

167.  and_then_expression  relation  and_then  relation 

168.  and_then_expression  and_then_expression  or_else 

relation 

169.  and_then  AND  THEN 

170.  or_else_expression  relation  or_else  relation 

171.  or_else_expression  or_else_expression  or_else 

relation 

172.  or_else  OR  ELSE 

173.  relation  simple_e xpression 

174.  relation  simple_expr ession  *  simple_expression 

175.  relation  simple_expression  /■  simple_expression 

176.  relation  simple_expr ession  <  simple_expression 

177.  relation  simple_expr ession  <-  simple_expr ession 
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178. 

179. 

180. 
181  . 
182. 

183  . 

184. 

185. 

186. 

187. 

188. 

189. 

190. 

191. 

192. 

193. 

194. 

195. 

196. 

197. 

198. 

199. 

200. 
201 . 
202. 
203. 


relation  : :  = 

simple_ex pres si on 

> 

simp le_e xpression 

relation  :  :  = 

simple_expr ession 

>= 

simple_e xpression 

relation  :  :  = 

simple_expression 

IN 

subt ype_indi cation 

relation  :  :  = 

simple_expr ession 

IN 

range 

relation  ::= 

s  i  m  p  1  e_  e  .<  p  r  e  s  s  i  on 

NOT 

IN 

sut  t  y pe_ind icat ion 

relation  :  :  = 

s i m  p 1 e_e  xpression 

NOT 

IN  range 

unop_term  : : 

*  +  term 

unop_term  :  : 

*  -  term 

unop_term  :  : 

=  NOT  term 

simp le_e xpression 

; :  = 

simple_expression  + 

term 

simple_e  xpression 

: :  = 

simple__e  xpression 

term 

s i m  p 1 e_e  xpression 

: :  = 

simple_expression  & 

term 

simple_expression 

{  J  s 

term 

simp le_e  xpression 

S  J  a 

unop_term 

term 

•  •  s 

term 

*  factor 

term 

5  2  s 

term 

/  factor 

term 

term 

MOD  factor 

term 

term 

REM  factor 

term 

: :  = 

factor 

factor  :  : «=  primary 

factor  primary  **  primary 

primary  literal 

primary  : : =  name 

primary  allocator 

primary  name  ’  generalized_expression_list 

primary  generalized_expression_list 
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204.  allocator  NEW  name 

205.  statement_list  ::=  statement  ; 

206.  statement_list  statement_list  statement  ; 

2C7.  statement  ::=  opt_label_list  unlabelled_statement 

208.  statement  ::=  pragma 

209.  opt_label_list  ::= 

210.  opt.  label_list  label_list 


211  . 

label_list  label 

212. 

label_list  label. 

_list  label 

213. 

unlabelled_sta tement 

::=  simple_statement 

214. 

unlabelled_statement 

::=  compound_statement 

215. 

simple_statement  ::= 

assignment_statenie"t 

216. 

simple_statement 

name 

217. 

simple_statement  : :  *> 

exit_statement 

218. 

simple_statement  ::*= 

return_sta tement 

219. 

simple_statement 

goto_statement 

220. 

simple_sta tement  ::= 

raise_sta tement 

221  . 

simple_statement 

abort_statement 

222. 

simple_statement  : : * 

delay_statement 

223. 

slmple_statement 

name  '  generalized_expression_ 

224. 

slmple_statement 

NULL 

225. 

compound_statement  : 

:=  if_statement  END  IF 

226. 

compound_statement  : 

:■  case_statement  END  CASE 

227. 

compound_statement  : 

:*  accept_statement 

228. 

compound_statement  : 

s®  select_statement  END  SELECT 

229. 

compound_statement  : 

loop_statement  END  LOOP 
i  d_o  p  t i o  n 

230. 

compound_statement  : 

block  END  id_option 
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231.  tag_option  ::= 

232  .  t a g_o ption  id  : 

233.  label  <<  id  >> 

234.  assignment_statement  ::=  name  becomes  expression 

235.  if__sta tement  =  if_head 

236.  if_^statement  ::=  if_head_else  statement_list 

237.  if__head  ::=  if_condition  THEN  statement_list 

238.  if_head  if_head_elsif_condition  THEN  statement_list 

239.  if^condition  ::=  IF  condition 

240.  if_head_elsif_condition  if_head_elsif  condition 

241.  if__head_elsif  ::=  if_head  ELSIF 

242.  if__head_else  if_head  ELSE 

243.  condition  expression 

244.  case_statement  ::*=  case_header  alternati ve_list_option 

245.  case_header  :  :  *=  CASE  expression  IS 

246.  alternative_list_option  ::= 

247.  alternative_list_option  ::=  alternative__list 

248.  alternative_list  =  alternative 

249.  alternati ve_list  alternati ve_list  alternative 

250.  alternative  pre_alternative  statement_list 

251.  pre_alternative  WHEN  choice_list  »> 

252.  loop_statement  ::*>  tag_option  loop_intro  statement_list 

253.  loop_intro  LOOP 

254.  loop_intro  WHILE  condition  LOOP 

255.  loop_intro  FOR  id  IN  re verse_option 

discrete_range  LOOP 

256.  reverse_option 
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257.  re verse_option  ::=  REVERSE 


258.  block  tag_option  declare_part_option  block_body 

259.  declare_part_option 

260.  declare_part_option  declare_kw  declar ati ve_part 

261.  declare_kw  DECLARE 

262.  block_body  BEGIN  statement_list  exception_option 

263.  exception_option  ::= 

264.  exception_option  ::=  EXCEPTION 

exception_handler_list__option 

265.  exit_statement  ::=  EXIT  id_option  when_condi tion_option 

266.  when_condition_optlon  : : * 

267.  when__condition_option  : : «*  WHEN  condition 

268.  return_statement  ::=  RETURN  expression_option 

269.  goto_statement  GOTO  name 

270.  subprogram_declaration  subp_spec 

271.  subprogram_declaration  gen__inst_subp 

272.  subprogram_declaration  ::=  subp_spec  IS  SEPARATE 

273.  subprogram_declaration  subp_body_dcl 

274.  gen_inst_subp  subp_spec_is  NEW  name 

275.  subp_spec  subp_hdr 

276.  subp_spec  generic_part  subp_hdr 

277.  subprogram_nature  FUNCTION 

278.  subprogram_nature  : :  «*  PROCEDURE 

279.  subp_hdr  subprog_nature_desig  formal__part_option 

r  etur  n__option 

280.  aubprog  nature  desig  subprogram_nature  designator 

281.  subp_spec_is  subp__spec  IS 

282.  subp_body_dcl  subp_spec_is_dp  block_body  END 

de signs tor_option 
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283. 

subp_spec_ 

,is_dp  = 

subp_ 

,spec_ 

_is  declarative_par t 

284. 

designator 

_option  ::= 

285. 

designator 

_o  p  t i o  n  : :  = 

desi 

gnator 

286. 

designator 

:  :  =  id 

287. 

designator 

string 

288. 

return_opt 

ion  : :  = 

289. 

return_opt 

ion  RETURN 

subt ype_in dicat ion 

290. 

formal  par 

t_option  : : 

= 

291 . 

formal  par 

t_option  : : 

=  ( 

parameter_declaration_list  ) 

292. 

parameter_ 

declaration 

_list 

parameter_declaration 

293. 

parameter_ 

declaration 

_list 

•  • 

•  •  “ 

parame 

ter_declara 

tion_ 

list 

:  parameter_declaration 

294. 

parameter 

.declaration 

•  •  «- 

identif ier_list  :  mode_option 

subtype^indication 

ini tialization_option 

295. 

parameter 

declaration 

•  •  «- 
•  •  = 

id  : 

mode__option 

subtype^indication  ini tialization_option 


296.  mode_option  : :  «* 

297.  mode_option  IN 

298.  mode_option  OUT 

299.  mode_option  IN  OUT 


300.  package_declaration  pkg_spec_dcl 

301.  package_declaration  gen_inst_pkg 

302.  package_declaration  PACKAGE  BODY  id  IS  SEPARATE 

303.  package_declar ation  pkg_body_dcl 

304.  gen_inst_pkg  pkg_spec_hdr  IS  NEW  name 

305.  pkg_spec_dcl  pkg_spec_hdr_is_dp 

private_decl_part_option  END  id_option 

306.  pkg_spec_hdr_is_dp  pkg_spec_hdr_is  declarative_part 

307.  pkg_spec_hdr  pkg__spec_hdr  IS 
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308.  pkg_spec_hdr  ::*=  generic_part  pkg_header 

309.  pkg_spec_hdr  pkg__header 

310.  pkg_header  PACKAGE  id 

311.  pkg_body_dcl  pkg__body_is_stms  END  id_option 

312.  pkg_body_is_stms  pkg_body_is_dp  block_body 

313.  pkg_body_is_stms  ::=  pkg_body_is_dp 

314.  pkg_body_is_dp  pkg_body_is  declarative_part 

315.  pkg_body_is  PACKAGE  BODY  id  IS 

316.  pri vate_decl_par t_option  ::*> 

317.  pri vate_decl_par t_option  ::■>  PRIVATE  declarative_part 

318.  pri vate_type_def inition  ::=  PRIVATE 

319.  pri vate_type_def inition  ::=  LIMITED  PRIVATE 

320.  use_clause  USE  name_list 

321.  renaming_declaration  ::•*  id  :  constant_option  name 

RENAMES  name 

322.  renaming_declaration  =  id  ;  EXCEPTION  RENAMES  name 

323.  renaming_declaration  subp_hdr  RENAMES 

subprogram_name 

324.  renaming_declaration  PACKAGE  id  RENAMES  name 

325.  renaming_declaration  TASK  opt_type_kw  id 

RENAMES  name 

326.  task_header  TASK  opt__type_kw  id 

327.  task_declaration  task_header  opt_task_is 

328.  task_declaration  task_body 

329.  task_declaration  task_body_id_is  SEPARATE 

330.  task_body  task_body_id_is_dp  block_body 

END  id_option 

331.  task_body_id_is_dp  task_body_id_is  declarative_part 

332.  task_body_id_is  TASK  BODY  id  IS 
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TYPE 


333. 

334. 

335. 

336. 

337. 

338. 

339. 

340. 

341. 

342. 
.343. 

344. 

345. 

346. 

347. 

348. 

349. 

350. 

351. 

352. 

353. 

354. 

355. 

356. 

357. 


opt_type_kw  ::= 
opt_type_kw  : :  = 
opt_task_is 

opt_task_is  ::=  IS  opt_entries  r ep_spec_list_option 

END  id_option 

reP_spec_list_option  ::= 

rep_spec_lis t_option  rep_spec_list 

rep_spec_list  : :  ■  r ..  presentation_specif  icati  on  ; 

rep_spec__list  rep__ spec_list 

representation_specification  ; 

°pt_entries  : :  = 

opt_entries  entry_dcl_list 

entry_dcl_list  entr y_declaration  ; 

entry_dcl_list  entr y_dcl_list  entr y_declaration  ; 

synchronization_j3tatement  accept_statement 

synchronization_statement  delay_statement 

entr y_declaration  ;:**  ENTRY  id  (  discrete_range  ) 

formal_par  t__option 

entr y_declaration  =  ENTRY  id  formal  part_option 

accept_hdr  ACCEPT  id  f ormal_part_option 

accept_hdr  ACCEPT  paren_name  formal_part_option 

accept_statement  accept__hdr 

accept_statement  accept_hdr_do  statement_list  ENl' 

id_option 

accept__hdr_do  accept_hdr  DO 

paren_name  id  (  expression  ) 

delay_statement  DELAY  simp] e_expression 

select_8tatement  select__kw  select_body 

select_statement  select_kw  conditional_enti y_rall 
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358.  select_statement  ::=  select_kw  timed_entry_call 

359.  conditional_entr y_call  entry_list  else_kw 

statement_list 

360.  else_kw  ELSE 

361.  timed_entry_call  entry__list_or_del  stmt_list_option 

362.  entry__list_or_del  ::=  entry_list  OR  delay_statement  ; 

363.  entry_list  entr y_call_statement  stmt_list_option 

364.  entry__call_statement  ::=  name  ; 

365.  stmt_list_option 

366.  stmt_list_option  statement_list 

367.  select_kw  ::=  SELECT 

368.  select_body  select_alternative_list  else_kw 

statement_list 

369.  select_body  =  select_alternati ve_list 

370.  select_alternative_list  ::■=  select_alternati ve 

371.  select_alternati ve_list  select_alternati ve_list  OR 

select_al ter native 

372.  select_alt_f ront  condition_option 

synchronization_option  ; 

373.  select_alter native  select_alt_f  ront  statement_list 

374.  select_alter native  : select_alt_f ront 

375.  select_alternati ve  condition_option  TERMINATE  ; 

376.  condition_option 

377.  condition_option  WHEN  condition  »> 

378.  abort_8tatement  ABORT  name_list 

379.  comp_unithdr  pragma_list_option  context_list_option 

380.  compilation_unit  comp_unithdr  l_unit 

381.  compilation_unit  comp_unithdr  SEPARATE  ( 

designator_dot_name  )  s_unit 
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designator 


382.  designator_dot_name  ::= 

383.  designator_dot_name  ::=  designator_dot_name 

designator 


384.  s_unit 

: :  = 

c_body 

385.  s_unit 

: :  ■ 

task_body 

386.  c_body 

subp_body_dcl 

387.  c_body 

pkg_body_dcl 

388.  l_un.it 

$  {  B 

c_body 

389.  l_unit 

subp_spec 

390.  l_unit 

: :  * 

pkg_spec_dcl 

391 .  l_unit 

gen_inst_pkg 

392.  l_un*t 

: :  ■ 

gen_inst_subp 

393.  context_list_option 

394.  context:_list_option  context_list 

395.  context_list  context 

396.  context_list  context_list  context 

397.  context  with_clause 

398.  context  with_clause  use_clause  ; 

399.  vith_clause  WITH  name_list  ; 

400.  exception_declar ation  identif ier_list  :  EXCEPTION 

401.  exception_declaration  id  :  EXCEPTION 

402.  exception__handler_list_option 

403.  exception_handler_list_option 

exception_handler_list 

404.  exception_handler__list  exception_handler 

405.  exception_handler_list  exception_handler__list 

exception_handler 

406.  exception_handler  eh_pre_stm  statement_list 
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407.  eh_pre_stm  WHEN  exception_choice_list  «> 

408.  exception_choice_list  exception_choice 

409.  exception_choice_list  ::=  exception_choice_list 

vertical_bar  exception_choice 

410.  exception_choice  name 

411.  exception_choice  ::=  OTHERS 

412.  raise_statement  ::=  RAISE  name 

413.  raise_statement  ::=  RAISE 

414.  generic^ formal_list_option 

415.  generic_f ormal_list_option  ::=  generic_formal_list 

416.  generic__part  GENERIC  generic_f  ormal_list_option 

417.  generic_formal_list  ::  =  generic_f ormal  ; 

418.  generic_formal_list  generic_f ormal_list 

generic_f  ormal  ; 

419.  generic_formal  parameteri_declaration 

420.  generic_formal  TYPE  id  discriminant_part_option 

IS  generic__type_def  inition 

421.  generic_formal  WITH  subp_hdr 

422.  generic_f ormal  WITH  subp_hdr  IS  subprogram_name 

423.  generic_formal  WITH  subp__hdr  IS  <> 

424.  generic_type_def inition  (  <>  ) 

425.  generic_type_def inition  RANGE  <> 

426.  generic_type_def inition  DELTA  <> 

427.  generic_type_def inition  DIGITS  <> 

428.  generic_type_def inition  srray_type_def ini tion 

429.  generic_type_def inition  8ccess_type_def inition 

430.  generic_type_def inition  pri vate_type_def inition 

431.  representation_specification 

length_spec_or_enum_rep 
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432.  representation_speci f ication 

recor  d_type_representation 

433.  representation_specification  address_specification 

434.  length_spec_or_enum_re p  FOR  name  USE  expression 

435.  record_type_representation  f or_name_use_recor d 

alignment_clause_option  corop_name_loc_list_option 
END  RECORD 

436.  f or_name_use_r ecor d  ::=  FOR  name  USE  RECORD 

437.  alignment_clause_option  = 

438.  alignment_clause_option  ::=  AT  MOD  simple_expression  ; 

439.  comp_name__loc_li st_option 

440.  compJLname_loc_list_option  =  comp_name_loc_list 

441.  comp_name_loc_list  : :  ■»  comp_name_loc  ; 

442.  comp_name_loc_list  =  comp_name_loc_list 

comp_name__l°c  ; 

443.  comp__name__loc  name  AT  simple_expression 

r an ge_  constraint 


444.  address_specif ication 


FOR  name  USE  AT 
simple_expr ession 


Appendix  D 


Removal  of  Language-features  from  Valid  Tests 


The  purpose  of  this  appendix  is  to  show  that  the  tests 
found  in  the  AC VC  can  still  be  useful  after 
language-features  have  been  removed  from  them.  It  provides 
an  example  of  a  Class  A  test  and  shows  what  it  would  look 
like  after  some  features  have  been  removed.  Figure  D-l  shows 
the  test  to  be  evaluated. 

The  first  case  studied  is  the  impact  the  removal  of 
record  structures  would  have  on  the  test.  Figure  D-2 
illustrates  what  the  test  would  look  like  after  all  uses  of 
the  record  structure  were  removed.  The  only  test  objective 
not  accomplished  by  the  test  is  testing  the  acceptance  of 

The  remainder  of  the  test  is  still  valid. 

If  the  array  is  added  to  the  list  of  unsupported 
features  the  resulting  test  would  look  like  the  test  shown 
in  figure  D-3.  The  use  of  ’(',  ')',  *  I  ’ ,  and 

would  no  longer  be  tested,  but  the  remaining  test  would  be 
valid . 

This  process  can  continue  until  all  that  remains  is  the 
procedure  calls  to  TEST  and  RESULT,  provided  they  were 
recoded  using  the  supported  language  features.  When  the 
string  type  is  no  longer  supported  the  TEST  procedure  call 
would  be  an  illegal  construct. 


WITH  REPORT; 

PROCEDURE  A21C01A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED”  ); 
DECLARE 


TYPE  TABLE  IS  ARRAY  (1..10)  OF  INTEGER; 

A  :  TABLE  :=  (2  I  4  |  10  =>  1  ,  1  I  3  I  5..9  *>  0 

—  USE  OF  :  (  )  |  , 


TYPE  BUFFER  IS 

RECORD 

LENGTH  :  INTEGER; 

POS  :  INTEGER; 

IMAGE  :  INTEGER; 

END  RECORD;  -  USED  TO  TEST 


R1  :  BUFFER; 


LATER 


ABCDEFGHIJKLM  :  INTEGER; 
NOPQRSTUVWXYZ  :  INTEGER; 
ZJ.234567890  ;  INTEGER; 
II,  12,  13  :  INTEGER; 

Cl,  C2  ;  STRING  (1..6); 
C3  :  STRING  (1. .12); 


—  USE  OF  ABCDEFGHIJKLM 

—  USE  OF  NOPQRSTUVWXYZ 

—  USE  OF  1234567890 


BEGIN 


11 

:» 

2  *  (  3  -  1  +  2  ) 

/  2  ;  12  ; 

;*  8  ;  —  USES  ( 

Cl 

"ABCDEF”  ; 

—  USE 

OF 

ft 

C2 

:» 

Cl; 

C3 

Cl  &  C2  ; 

—  USE 

OF 

& 

12 

:» 

16#D#; 

—  USE 

OF 

# 

13 

:■ 

A'LAST; 

—  USE 

OF 

I 

Rl, 

,POS  3; 

—  USE 

OF 

• 

IF 

11 

>  2  AND 

11 

-  4  AND 

11 

<  8  THEN 

—  USE 

OF 

>  -  < 

NULL; 
END  IF; 


END; 
RESULT; 
END  A21001A; 


Figure  D-l.  Class  A  Test 
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WITH  REPORT; 

PROCEDURE  A21C01A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED"  ); 
DECLARE 

TYPE  TABLE  IS  ARRAY  (1..10)  OF  INTEGER; 

A  :  TABLE  :=  (2  |  4  I  10  ■>  1  ,  1  |  3  I  5..9  **>  0  )  ; 

—  USE  OF  :  (  )  |  , 


ABCDEFGHIJKLM  :  INTEGER 
NOPQRSTUVWXYZ  ;  INTEGER 
Z_1 234567890  ;  INTEGER 
II,  12,  13  :  INTEGER; 

Cl,  C2  ;  STRING  (1. .6); 


—  USE  OF  ABCDEFGHIJKLM 

—  USE  OF  NOPQRSTUVWXYZ 

—  USE  OF  1234567890 


C3  ;  STRING  (1. .12); 

BEGIN 

11  2  *  (  3  -  1  +  2  ) 

/  2  j  12  s-  8. 

Cl  "ABCDEF"  ; 

—  USE  OF  " 

C2  :»  Cl; 

C3  Cl  &  C2  ; 

—  USE  OF  & 

12  16#D#; 

—  USE  OF  # 

13  A'LAST; 

—  USE  OF  ' 

IF  11  >  2  AND 

II  -  4  AND 
II  <  8  THEN 
NULL; 

END  IF; 

END; 

RESULT; 

END  A21001A; 


—  USE  OF  >  -  < 


Figure  D-2.  Class  A  Test  with  record  removed 


WITH  REPORT; 

PROCEDURE  A21001A  IS 

USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT 

BASIC  CHARACTER  SET  IS  ACCEPTED"  ); 

DECLARE 

ABCDEFGnIJKLM  :  INTEGER; 

—  USE  OF  ABCDEFGHIJKLM 

NOPQRSTUW.XYZ  :  INTEGER; 

--  USE  OF  NOPQRSTUVW’XYZ 

Z  123456 7890  :  INTEGER; 

—  USE  OF  1234567890 

11,  12,  13  :  INTEGER ; 

Cl,  C2  :  STRING  ( 1 . .6) ; 

C3  :  STRING  (1..12); 

BEGIN 

11  2  *  (  3  -  1  +  2  )  /  2 

;  12  8  ;  —  USES  ()*  +  -/; 

Cl  "ABCDEF"  ; 

—  USE  OF  " 

C2  :  =  Cl; 

C3  Cl  &  C.2  ; 

—  USE  OF  & 

12  16#D#; 

—  USE  OF  # 

IF  11  >  2  AND 

11-4  AND 

11  <  8  THEN 

—  USE  OF  >  -  < 

NULL; 

END  IF; 

END; 

RESULT; 

END  A21001A; 

• 

Figure  D-3.  Class  A  Test  with  records  and  arrays  removed 


Class  A  tests  in  most  cases  still  accomplish  many  of 
the  test  objectives  even  when  language-features  are  removed. 
In  most  cases,  Class  C  and  Class  D  tests  do  not  accomplish 
their  test  objectives  when  features  are  removed.  The  prime 
purpose  for  removing  features  from  Class  C  and  Class  D  tests 
is  so  they  will  not  fail  compilation.  If  they  failed 
compilation,  they  would  require  manual  analysis  to  determine 
they  failed  because  they  used  unsupported  features. 
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APPENDIX  E 


Manual  Evaluation  of  Tests 


This  appendix  was  Included  to  show  the  manual  effort  required  to 
analyze  tests  contained  In  the  ACVC.  A  small  segment  of  the  test  shown 
in  figure  2-3  is  analyzed  using  the  BNF  contained  In  the  LRM  (Ref  1). 
The  segment  analyzed  is  shown  in  figure  E-l. 


WITH  REPORT; 

PROCEDURE  A21001A  IS 
USE  REPORT; 

BEGIN 

TEST  ("A21001A",  "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED"  ); 
DECLARE 

TYPE  TABLE  IS  ARRAY  (1..10)  OF  INTEGER; 

A  ;  TABLE  s-  (2  I  4  I  10  ->  1  ,  1  I  3  l  5.. 9  ->  0  )  ; 

—  USE  OF  :  (  )  |  , 

END; 


Figure  E-l.  Test  Segment  Analyzed  Manually 


In  the  following  analysis,  the  code  being  analyzed  is  found  between 


the  asterisks 


TEST  A21001A.ADA 


WITH  REPORT; 


Ufcj 
i  w 


compilation  compilation_unit 


compilation., unit  context_apecification 

subprogramjbody 


context_specification  vith_clause 
with_clause  WITH  unit_name; 
name  identifier 

identifier  letter  ^letter_or_jdigit^ 

letter  : :■  upper_case_letter 


PROCEDURE  A21001A  IS 


subprogram_J>ody  subprogram,. specification  IS 

declarative_j>art 

BEGIN 

sequence_of_statements 
END  [designator]; 


8ubprogram_specification  PR0CEDT1RE  identifier 
identifier  : :»  letter  ^etter_orjdigit^ 
letter  upper_case_letter 


USE  REPORT  ; 


declarative _part  : ;■  declarative_item 
declarative_it«n  : :■  usejclause 
uae_clauae  : :■  USE  package_name 
name  identifier 

identifier  letter  ^letter_or_digit^ 
upper_caae_letter 


letter 


TEST(  ’A21001A” , "CHECK  THAT  BASIC  CHARACTER  SET  IS  ACCEPTED") 


statement  simple_statement 
simple_statement  : procedure__call 

procedure_call  : :»  procedure_name  [actual_j>araineter_part] 
name  identifier 

identifier  letter  ^Le tter_or_di gi t^ 
letter  : :■  up per_case_le t ter 

actual  parameter  part  ( parameter_association 

, parameter_association|) 

"A21001A"  wwiwwmuiiiwhi 

paraneterjaesocietion  actual_paraaeter 

actual _parameter  expression 

expression  : :■  relation 

relation  : :■  simplejaxpresslon 

slaplejexpression  t:>  term 

term  : :»  factor 

factor  : primary 

primary  »:■  literal 

literal  :  :■  characters tring 


characterstring  "|character^r 


*******  "CHECK  that  basic  character  set  IS  ACCEPTED"" ******* 


parameter_association  actual_parameter 

actual_parameter  expression 

expression  : :■  relation 

relation  simple_expression 

sioplejexpression  : :»  term 

term  : :■  factor 

factor  primary 

primary  literal 

literal  character_string 

character_string  "^character^" 

WHHHHHHHHHHHHHHHHHHHHHHHI  DECLARE  ■«*«»*** 


statement  ; :■  compound_statement 
compound_statement  ! :■  block 


block  DECLARE 

declarative__part 

BEGIN 

sequence_of_statements 
END  [blockjLdentifier] 


declarative_part 


^declarative 


•jltem^ 


TYPE  TABLE  IS  * 


declarative_itea  declaration 

declaration  : type_dedaration 

typejdedaration  TYPE  identifier  IS  type_ definition; 

identifier  *:-  letter  ^Let t  er_or_di gi tj> 
letter  upper__case_letter 
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ARRAY  (1 .  .10)  OF  INTEGER  HHUHIIMIMW 

type_definition  arrayjtypejdefinition 

array_type_de£inltion  : :■  ARRAY  index_constraint  OF 

component_subtype_indication 

index_constraint  : ;■  (discrete__renge) 

discrete_range  : :■  range 

range  :s«  simple_expression. .simple_expression 


1 


simplejexpression  :  :■  term 
Cera  t :■  factor 
factor  primary 
primary  literal 

literal  : miner lc_li ter al 
nunerlc_literal  j:»  deciaal_number 
decinel_nuaber  integer 
Integer  digit  ^igitV 


10 


slmple_expresaion  term 

tern  :  :«•  factor 

factor  : :■  primary 

primary  : literal 

literal  : :■  numeric_literal 

nunerlc_literal  deciael_n unbar 

decinal_nuaber  : j-  integer 

integer  : !■  digit  ^digitV 
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INTEGER  ****** 

subtypejLndication  typejnark 
typejnark  type_na*e 

name  Identifier 

identifier  letter  |l  e  1 1 er_or_d i gi t^> 

letter  upperjcasejletter 


****  A  s  TABLE  s-  (2  !  4  I  10  ->  1,  1  I  3  I  5.. 9  ->  0);  **** 

declared  ve__i  ten  declaration 

declaration  objectjdedaration 

objectjdedaration  :  :■  identifier_liat: 

aubtype_lndication  [:■  expression] 

. . .  A  . —■■■■■■■■■■■■■■—— 

identifier_li#t  identifier 
identifier  letter  ^letter_or_digit^ 
letter  upper_caae_letter 


————— . .  TABLE  — . . 

subtype_lndicatlon  type__nark 

typejnark  typejiame 

naue  identifier 

identifier  letter  ^letter_or_digit| 
letter  upper_caae_letter 

. « . —  (2I4|10  ->  1,  It 3 IS. .9  ->  0) 

expression  : :■  relation 
relation  aiapl#_expreaaion 
siaplejtxpreaaion  : tern 
tern  factor 
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factor  primary 
primary  (expression) 

expression  relation 
relation  : :■  simplejexpression 
simplejexpression  term 
term  factor 
factor  : :■  primary 
primary  aggregate 

aggregate  :  :■  (component_association<j,coniponent_associatioi}) 


21  4  |  10  ->  1 


component_a8sociation  : :■  [choice  choice}  »>]  expression 


<HHHHnnHHnt*<Hni«aini  see  see  news  2  *** 

choice  : :■  simplejexpression 
simplejexpression  term 
term  factor 
factor  l :■  primary 
primary  : :■  literal 
literal  : :■  numeric_llteral 
numerical  iter el  decimal ^number 

decimaljDumber  Integer 
integer  : :■  digit  {digit} 


. . .  4 

choice  :>■  simplejexpression 
simplejexpression  term 
term  factor 
factor  : primary 
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literal 


primary 
literal  numeric_literal 

numeric__literal  I :■  decimal_n umber 
decimal_number  integer  [.integer]  [exponent] 
integer  digit  £[  underscore]  digitj> 


choice  simple__expression 
simple_expression  term 
term  :  :■  factor 
factor  : :■  primary 
primary  literal 

literal  :  :■  numeric__literal 
numeric_llteral  decimal_number 
decimal_number  integer 
Integer  digit  {digit'V 


IHHHHHHHHHHHHHHHHHHHHHHHHHHHt  J  4HHH 

expression  relation 

relation  simplejexpression 

slmplejexpression  : term 

term  factor 

factor  : :■  primary 

primary  ::»literal 

literal  $:■  numerical iteral 

numeric JLiteral  dec imal_n umber 

decimal_nuaber  : j-  Integer 

integer  s  *■  digit  ^digit^ 
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1  |  31  5. .9  ->  0 


component_association  [choice  choice^  ■>]  expression 


choice  simple_expression 

simple_expression  term 

term  factor 

factor  primary 

primary  literal 

factor  : :■  primary 

primary  : :■  literal 

literal  : :■  numeric_literal 

numericJLlteral  : :»  decimal_nunber 

decimal_nunber  integer 

integer  digit  ^digit^ 


choice  : :■  simple_expression 
simplejexpresslon  term 
term  factor 
factor  : :■  primary 
primary  literal 

numeric_literal  $ :■  decimal_n umber 
decimal __puaber  Integer 
integer  digit  ^digit^ 
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5. .9 


choice  discrete_range 
discrete__range  range 

range  simple_expression . . simple_expreasion 

5 


number 


9  **hh 

simple_expresslon  ten 

ten  :  :■  factor 

factor  : :*  primary 

primary  : :•  literal 

numeric_literal  : >  decimal_number 

decimal_nuaber  : :■  integer 

integer  digit  ^digit^ 

SIHHHHHHHHHHHHHHHHHHHHHHHHHHt  0  *** 

expression  relation 
relation  simple_expression 
simplejMpression  *:•  ten 
ten  :  ;■  fsctor 
factor  primary 


simple_expression  term 
term  factor 
factor  primary 

primary  ::<■  literal 
numerical! teral  :  :■  decimal_ 
decimal_number  : :■  integer 
integer  digit  ^digitj* 
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primary  : :«literal 

literal  numeric_literal 

nuDieric_literal  decimal_number 

decimal_number  integer 
r  -> 

integer  : :«  digit  -jjiigit  j 


APPENDIX  F 


Description  of  the  Garlington  Compiler 

This  appendix  describes  the  Ada  compiler  used  to  parse 
the  test  programs.  It  was  developed  by  Alan  Garlington  as 
part  of  his  thesis  effort  in  the  design  and  implementation 
of  an  Ada  pseudo-machine  (Ref  5). 

The  portion  of  the  user's  guide  which  describes  the 
features  implemented  is  reproduced  here  for  convenience. 


1.  Integer  Variables.  Number  declarations  and  variable 
initializations  are  not  implemented. 

2.  Package  declarations. 

3.  Procedures  and  functions  with  parameters  (mode  types 
may  be  specified). 

4.  Task  declarations. 

5.  Selected  components  may  be  used  to  open  visibility 
to  objects  that  are  within  scope  but  which  are  not 
directly  visible. 

6.  Most  integer  arithmetic  or  Boolean  expressions  may 
be  used  including  those  using  short  circuit  conditions. 
However,  the  following  list  of  operators  has  not  been 
implemented:  REM,  **,  &,  IN. 

7.  The  following  statements  may  be  used: 

a.  Assignment 

b.  Procedure,  function  or  entry  calls 

c.  Exit 

d.  Return 

e.  IF  THEN  ELSIF  ELSE 

f.  Accept 

g.  Loops  (except  FOR  loop) 
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t  «■ 


The  aspect  of  the  Garlington  compiler  which  had  the 
most  significant  influence  on  this  project  was  the  parser. 
The  parser  used  by  Garlington  was  a  LR  (1)  parsing 
automaton.  It  is  a  bottom-up,  finite-state  machine  whose 
I  operations  are  directed  by  a  set  of  language-specific 

tables.  These  tables  were  generated  using  the  LR  package 
from  Lawrence  Livermore  Laboratory  (Ref  8).  The  parser  utad 
was  designed  to  parse  the  full  Ada  language  as  described  in 
the  1980  version  of  the  "Reference  Manual  for  the  Ada 
Programming  Language". 

{ 
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APPENDIX  G 


Modifications  to  the  Garlington  Compiler 

This  appendix  describes  the  changes  made  in  the 
Garlington  compiler  in  order  to  get  it  to  compile  on  the  VAX 
11-780.  There  were  four  primary  changes  made  to  the 
Garlington  compiler. 

The  first  change  required  was  a  case  conversion.  The 
version  taken  off  the  DEC-10  was  written  in  all  upper-case 
letters.  To  compile  on  the  VAX,  all  reserved  words  must  be 
in  lower-case.  The  program  was  run  through  a  case  conversion 
routine  to  change  it  to  lower  case. 

The  second  change  removed  all  line  numbers  from  the 
program.  This  was  accomplished  using  a  program  to  filter  out 
line  numbers. 

The  third  change  removed  all  CTBER  and  DEC-10  specific 
routines.  This  included  the  date  and  time  facilities  used  by 
the  compiler. 

The  final  and  probably  most  serious  modification  was 
related  to  the  structure  of  the  case  statements  used  in  the 
program.  The  version  of  Pascal  implemented  on  the  DEC-10 
supported  the  use  an  OTHERS  form  to  catch  anything  that  fell 
through  the  case  statement.  The  version  implemented  on  the 
VAX  does  not  support  the  OTHERS  statement.  This  required 
inserting  a  range  check  before  each  case  statement. 


APPENDIX  H 


Empty  Productions 

This  appendix  contains  a  list  of  all  the  empty  and 
potentially  empty  productions  found  in  the  BNF  contained  in 
Appendix  C.  These  productions  are  listed  by  their 
corresponding  number. 


2 

54 

120 

3 

55 

121 

14 

74 

145 

15 

75 

146 

19 

101 

209 

20 

102 

210 

25 

103 

231 

26 

104 

232 

48 

111 

246 

49 

112 

247 

50 

114 

256 

51 

115 

257 

259 

296 

341 

260 

297 

342 

263 

298 

365 

264 

299 

366 

266 

316 

267 

317 

284 

333 

285 

334 

288 

335 

289 

336 

290 

337 

291 

338 
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APPENDIX  I 


Recursive  Productions 

This  appendix  contains  a  list  of  all  the  recursive  and 
potentially  recursive  productions  found  in  the  BNF  contained 
in  Appendix  C.  These  productions  are  listed  by  their 
corresponding  number. 


4 

84 

148 

188 

292 

404 

5 

85 

149 

189 

293 

405 

16 

95 

161 

192 

339 

408 

17 

96 

162 

193 

340 

409 

21 

105 

163 

194 

343 

417 

22 

106 

164 

195 

344 

418 

27 

116 

165 

205 

370 

441 

28 

117 

166 

206 

371 

442 

56 

122 

167 

211 

382 

57 

123 

168 

212 

383 

79 

124 

170 

248 

395 

80 

125 

171 

249 

396 
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This  project  consisted  of  a  preliminary  design  and  a  partial  implementation  of 
a  tool  vhich  modifies  the  existing  Ada  Compiler  Validation  Capability  (ACVC)  test 
set  so  it  can  be  used  to  test  evolving  Ada  compilers.  The  project  evaluated  the 
feasibility  of  repackaging  each  of  test  classes  found  in  the  ACVC  and  suggested 
methods  for  repackaging  the  tests.  The  tool  developed  uses  a  table-driven 
parser  which  parses  the  July  1980  proposed  standard.  It  uses  output  from  the 
parser  to  generate  a  representation  of  a  test  program.  Once  the  representation 

DO  ,  j2Tt»  1473  EDITION  OF  1  NOV  •»  It  OBSOLETE  UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  TniS  FAOE  (Bhon  Onto  tnfet* 

ikcSW.1 


SeCUHITV  CLASSIFICATION  or  THIS  PAOti'W*"  Dim  Bntmni) 


Block  20 


Is  developed,  unsupported  language-features  are  removed  from  It.  The 
remaining  representation  is  output  as  a  valid  test  program. 


